There is currently an odd behaviour when locally cloning a repository
with symlinks at .git/objects: using --no-hardlinks all symlinks are
dereferenced but without it, Git will try to hardlink the files with the
link() function, which has an OS-specific behaviour on symlinks. On OSX
and NetBSD, it
There is currently an odd behaviour when locally cloning a repository
with symlinks at .git/objects: using --no-hardlinks all symlinks are
dereferenced but without it, Git will try to hardlink the files with the
link() function, which has an OS-specific behaviour on symlinks. On OSX
and NetBSD, it
There is currently an odd behaviour when locally cloning a repository
with symlinks at .git/objects: using --no-hardlinks all symlinks are
dereferenced but without it, Git will try to hardlink the files with the
link() function, which has an OS-specific behaviour on symlinks. On OSX
and NetBSD, it
On Sun, Mar 31, 2019 at 2:40 PM Thomas Gummerer wrote:
>
> On 03/30, Matheus Tavares wrote:
> > There is currently an odd behaviour when locally cloning a repository
> > with symlinks at .git/objects: using --no-hardlinks all symlinks are
> > dereferenced but without it,
On Sat, Mar 30, 2019 at 4:27 PM Thomas Gummerer wrote:
>
> On 03/30, Matheus Tavares Bernardino wrote:
> > On Fri, Mar 29, 2019 at 5:05 PM Thomas Gummerer
> > wrote:
> > >
> > > On 03/29, Matheus Tavares Bernardino wrote:
> > > > Ok, what if instead of using linkat() we use 'realpath(const char
On 03/30, Matheus Tavares wrote:
> There is currently an odd behaviour when locally cloning a repository
> with symlinks at .git/objects: using --no-hardlinks all symlinks are
> dereferenced but without it, Git will try to hardlink the files with the
> link() function, which has an
There is currently an odd behaviour when locally cloning a repository
with symlinks at .git/objects: using --no-hardlinks all symlinks are
dereferenced but without it, Git will try to hardlink the files with the
link() function, which has an OS-specific behaviour on symlinks. On OSX
and NetBSD, it
On 03/30, Matheus Tavares Bernardino wrote:
> On Fri, Mar 29, 2019 at 5:05 PM Thomas Gummerer wrote:
> >
> > On 03/29, Matheus Tavares Bernardino wrote:
> > > Ok, what if instead of using linkat() we use 'realpath(const char
> > > *path, char *resolved_path)', which will resolve any symlinks at
>
On Fri, Mar 29, 2019 at 5:05 PM Thomas Gummerer wrote:
>
> On 03/29, Matheus Tavares Bernardino wrote:
> > On Thu, Mar 28, 2019 at 7:10 PM Thomas Gummerer
> > wrote:
> > > I notice that we are currently not using 'linkat()' anywhere else in
> > > our codebase. It looks like it has been introduc
On 03/29, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Mar 28 2019, Thomas Gummerer wrote:
> > I notice that we are currently not using 'linkat()' anywhere else in
> > our codebase. It looks like it has been introduced in POSIX.1-2008,
> > which sounds fairly recent by git's standards. So I wonder
On 03/29, Matheus Tavares Bernardino wrote:
> On Thu, Mar 28, 2019 at 7:10 PM Thomas Gummerer wrote:
> > I notice that we are currently not using 'linkat()' anywhere else in
> > our codebase. It looks like it has been introduced in POSIX.1-2008,
> > which sounds fairly recent by git's standards.
Hi Thomas,
On Thu, 28 Mar 2019, Thomas Gummerer wrote:
> On 03/22, Matheus Tavares wrote:
> >
> > diff --git a/builtin/clone.c b/builtin/clone.c
> > index 50bde99618..b76f33c635 100644
> > --- a/builtin/clone.c
> > +++ b/builtin/clone.c
> > @@ -443,7 +443,7 @@ static void copy_or_link_directory(s
On Thu, Mar 28, 2019 at 7:10 PM Thomas Gummerer wrote:
>
> On 03/22, Matheus Tavares wrote:
> > There is currently an odd behaviour when locally clonning a repository
> > with symlinks at .git/objects: using --no-hardlinks all symlinks are
> > dereferenced but without it
On Thu, Mar 28 2019, Thomas Gummerer wrote:
> On 03/22, Matheus Tavares wrote:
>> There is currently an odd behaviour when locally clonning a repository
>> with symlinks at .git/objects: using --no-hardlinks all symlinks are
>> dereferenced but without it Git will try to ha
On 03/22, Matheus Tavares wrote:
> There is currently an odd behaviour when locally clonning a repository
> with symlinks at .git/objects: using --no-hardlinks all symlinks are
> dereferenced but without it Git will try to hardlink the files with the
> link() function, which has an
There is currently an odd behaviour when locally clonning a repository
with symlinks at .git/objects: using --no-hardlinks all symlinks are
dereferenced but without it Git will try to hardlink the files with the
link() function, which has an OS-specific behaviour on symlinks. On OSX
and NetBSD, it
;
> I checked one of my past projects and I notice that
> ".git/objects/pack" directory exist but there is not anything in it.
> Now I want to know that what is causes of this problem? And what is
> work around for this problem? And also I want to know that can I
> continue
Hi everyone
I have asked this question in Super User but I have not got answer. I
have described details in the my question__ link in available in
bottom__ but for more information I add following info:
I checked one of my past projects and I notice that
".git/objects/pack" directory
x27;.git' directory".
To test the case when we are "deep inside the '.git' directory" the
test scripts used to perform a `cd .git/refs/heads`.
As there are plans to implement other ref storage systems, let's
use '.git/objects' instead of '.git/ref
>
> To test the case when we are "deep inside the '.git' directory" the
> test scripts used to perform a `cd .git/refs/heads`.
>
> As there are plans to implement other ref storage systems, let's
> use '.git/objects' instead of '.git/refs/heads' as the "deep inside
> the '.git' directory" path.
Seems reasonable to me. +1.
Michael
ctory" the
test scripts used to perform a `cd .git/refs/heads`.
As there are plans to implement other ref storage systems, let's
use '.git/objects' instead of '.git/refs/heads' as the "deep inside
the '.git' directory" path.
This makes it clear to read
/t/t0560-read-object-git.sh b/t/t0560-read-object-git.sh
new file mode 100755
index 00..4e8fc04dfd
--- /dev/null
+++ b/t/t0560-read-object-git.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+test_description='tests for long running read-object process passing git
objects'
+
+. ./test-lib.sh
+
+P
diff --git a/t/t0460-read-object-git.sh b/t/t0460-read-object-git.sh
new file mode 100755
index 00..2873b445f3
--- /dev/null
+++ b/t/t0460-read-object-git.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+test_description='tests for long running read-object process passing git
objects'
+
+. ./t
diff --git a/t/t0460-read-object-git.sh b/t/t0460-read-object-git.sh
new file mode 100755
index 00..2873b445f3
--- /dev/null
+++ b/t/t0460-read-object-git.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+test_description='tests for long running read-object process passing git
objects'
+
+. ./t
diff --git a/t/t0460-read-object-git.sh b/t/t0460-read-object-git.sh
new file mode 100755
index 00..2873b445f3
--- /dev/null
+++ b/t/t0460-read-object-git.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+test_description='tests for long running read-object process passing git
objects'
+
+. ./t
diff --git a/t/t0460-read-object-git.sh b/t/t0460-read-object-git.sh
new file mode 100755
index 00..d08b44cdce
--- /dev/null
+++ b/t/t0460-read-object-git.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+test_description='tests for long running read-object process passing git
objects'
+
+. ./t
On Sat, Jun 03, 2017 at 04:53:20PM -0400, Dun Peal wrote:
> I try to follow the best practice of regular repo maintenance, which
> afaik consists of running `git gc` every week or so.
>
> So I thought I had a well-maintained repository, and was quite
> surprised to discover some
Hi there,
I try to follow the best practice of regular repo maintenance, which
afaik consists of running `git gc` every week or so.
So I thought I had a well-maintained repository, and was quite
surprised to discover some very large .git/objects/pack/tmp_* files,
which apparently are entirely
gt; remote: Counting objects: 5932092, done.
>> remote: Compressing objects: 100% (154131/154131), done.
>> fatal: Unable to create temporary file
>> '$HOME/Dev/linux-stable/.git/objects/pack/tmp_pack_XX': Permission
>> denied
>> fatal: index-pack failed
>&
objects: 100% (154131/154131), done.
> fatal: Unable to create temporary file
> '$HOME/Dev/linux-stable/.git/objects/pack/tmp_pack_XX': Permission
> denied
> fatal: index-pack failed
>
> Since no file/directory created by git I cant tell why git isn't
nux-stable/.git/objects/pack/tmp_pack_XX': Permission
denied
fatal: index-pack failed
Since no file/directory created by git I cant tell why git isn't
able to create
"$HOME/Dev/linux-stable/.git/objects/pack/tmp_pack_XX".
If I try to create this file and directory I can cr
On Thu, Dec 24, 2015 at 2:17 PM, Thiago Farina wrote:
>
> When ever I make a commit (assume I'm changing a single file) and do a
> 'git push origin master', git says 'Counting objects: 6, done.'
>
> Does git makes 6 objects everytime? What are those objects?
1 commit object;
1 blob object for the
Hi,
When ever I make a commit (assume I'm changing a single file) and do a
'git push origin master', git says 'Counting objects: 6, done.'
Does git makes 6 objects everytime? What are those objects?
--
Thiago Farina
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body o
Evan Li writes:
> Why some of them are of 755 but some 700? How can I set all
> sub-directories under ‘objects’ to be of 755 mode?
Some people who are pushing into the repository have 077 and some
others have 022 as their umask, perhaps?
If that is the case, perhaps core.sharedRepository config
Greetings,
I have setup a git server for my company, but one problem I found is like the
following problem:
[root@localhost objects]# pwd
/home/git/repositories/testing.git/objects
[root@localhost objects]# ls -l
total 0
drwx-- 2 git git 59 Dec 11 03:04 0e
drwx-- 2 git git 59 Dec 11 03:1
I've tried your commit.
No more error messages.
Looking forward to the next git version.
Thanks.
On 13 November 2013 07:32, Duy Nguyen wrote:
> On Wed, Nov 13, 2013 at 10:04 AM, Bryan Turner wrote:
>>> but it's only available in v1.5.0-rc0 or rc1. Could you try that
>>> version?
>>
>> I believe
On Wed, Nov 13, 2013 at 10:04 AM, Bryan Turner wrote:
>> but it's only available in v1.5.0-rc0 or rc1. Could you try that
>> version?
>
> I believe you mean 1.8.5-rc0 or 1.8.5-rc1, is that correct?
Yes. Looks like my fingers are not controlled by my mind anymore.
--
Duy
--
To unsubscribe from th
On 13 November 2013 13:48, Duy Nguyen wrote:
> On Tue, Nov 12, 2013 at 9:38 PM, Лежанкин Иван wrote:
>> I use linux.
>>
>> I can't publish repo - it's proprietary, it weights ~300M unpacked,
>> and it uses references ~3Gb.
>> Error message doesn't contain "remote:" prefix.
>> The majority of open
On Tue, Nov 12, 2013 at 9:38 PM, Лежанкин Иван wrote:
> I use linux.
>
> I can't publish repo - it's proprietary, it weights ~300M unpacked,
> and it uses references ~3Gb.
> Error message doesn't contain "remote:" prefix.
> The majority of opened files have name like:
> objects/pack/pack-.[ pack |
I use linux.
I can't publish repo - it's proprietary, it weights ~300M unpacked,
and it uses references ~3Gb.
Error message doesn't contain "remote:" prefix.
The majority of opened files have name like:
objects/pack/pack-.[ pack | idx ]
They all are from referenced repo.
I have disabled gc in the
On Tue, Nov 12, 2013 at 3:02 PM, Лежанкин Иван wrote:
> I get this error message every time I want to do a `git push`.
> git version: 1.8.4.2
>
> Is it a known issue? Do you need additional info to investigate it?
What OS do you use? If the repository can be published, please do.
Compress the who
On Tue, 12 Nov 2013 12:02:38 +0400
Лежанкин Иван wrote:
> I get this error message every time I want to do a `git push`.
> git version: 1.8.4.2
>
> Is it a known issue? Do you need additional info to investigate it?
What does
ulimit -n
tells to you when you run it before executing `git push`?
1024
On 12 November 2013 13:34, Konstantin Khomoutov
wrote:
> On Tue, 12 Nov 2013 12:02:38 +0400
> Лежанкин Иван wrote:
>
>> I get this error message every time I want to do a `git push`.
>> git version: 1.8.4.2
>>
>> Is it a known issue? Do you need additional info to investigate it?
>
> What
I get this error message every time I want to do a `git push`.
git version: 1.8.4.2
Is it a known issue? Do you need additional info to investigate it?
Ivan.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info
tory themselves.
That's not the only line it prints:
error: garbage found:
.git/objects/pack/pack-8074dfd2b01f494a30f02d0374baa57632d26fea.commits
error: garbage found:
.git/objects/pack/pack-834c9dccca7634c2b225db1b5050a980cb2c2de0.commits
error: garbage found: .git/objects/
line "garbage: 4" exactly *loud*. I also
think that this is not about *motivating* you, but about giving
more information to the users to help them assess the health of
their repository themselves.
By the way, I wonder if we also want to notice .git/objects/garbage
or .git/objects/ga
> }
>
How about the below patch? Ignoring good .commits files will be just a
couple more lines in the "for (remembered_pack)" loop.
Also in another mail in this thread:
> I also wonder, especially because you are enumerating the temporary
> pack files in .git/objec
Nguyễn Thái Ngọc Duy writes:
> @@ -1024,11 +1035,15 @@ static void prepare_packed_git_one(char *objdir, int
> local)
> int namelen = strlen(de->d_name);
> struct packed_git *p;
>
> - if (!has_extension(de->d_name, ".idx"))
> + if (!has_exten
d_git() should be treated the
same way as other cases where the files readdir() found are truly
garbage, by the way.
I also wonder, especially because you are enumerating the temporary
pack files in .git/objects/pack/, if it make more sense to account
for their sizes as well. After all, you wo
While it's unusual to have strange files in loose object database,
.git/objects/pack/tmp_* is normal after a broken fetch and they
can eat up a lot of disk space if the user does not pay attention.
Report them.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
The hook in prepare_packed_git_one is
On Mon, 18 Apr 2005, Junio C Hamano wrote:
> > "DB" == Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> DB> On Mon, 18 Apr 2005, Linus Torvalds wrote:
> >> On Sun, 17 Apr 2005, Daniel Barkalow wrote:
> >> >
> >> > This series introduces common parsers for objects, and ports the programs
> >> >
On Mon, 18 Apr 2005, Junio C Hamano wrote:
> I was looking at the tree part and am thinking that it would
> make it much nicer if your tree object records path for each
> entry.
You're entirely right, and I've actually now written the code that does
it. I'm planning to send out a patch for that
> "DB" == Daniel Barkalow <[EMAIL PROTECTED]> writes:
DB> On Mon, 18 Apr 2005, Linus Torvalds wrote:
>> On Sun, 17 Apr 2005, Daniel Barkalow wrote:
>> >
>> > This series introduces common parsers for objects, and ports the programs
>> > that currently use revision.h to them.
>> >
>> > 1: the
On Mon, 18 Apr 2005, Linus Torvalds wrote:
> On Sun, 17 Apr 2005, Daniel Barkalow wrote:
> >
> > This series introduces common parsers for objects, and ports the programs
> > that currently use revision.h to them.
> >
> > 1: the header files
> > 2: the implementations
> > 3: port rev-tree
> >
On Sun, 17 Apr 2005, Daniel Barkalow wrote:
>
> This series introduces common parsers for objects, and ports the programs
> that currently use revision.h to them.
>
> 1: the header files
> 2: the implementations
> 3: port rev-tree
> 4: port fsck-cache
> 5: port merge-base
Ok, having now lo
This series introduces common parsers for objects, and ports the programs
that currently use revision.h to them.
1: the header files
2: the implementations
3: port rev-tree
4: port fsck-cache
5: port merge-base
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this
56 matches
Mail list logo
