threads / discuss / 7676

git-receive-pack doesn't understand objects/info/alternates?

Subject: git-receive-pack doesn't understand objects/info/alternates?

## tl;dr

6 messages between Apr 16, 2007 and Apr 16, 2007.

replies: 5people: 4as markdown or json

Theodore Ts'o· Apr 16, 2007, 12:22 UTC · lore

When I push a kernel repository to master.kernel.org, where the repository only has at most a dozen changes on top of 2.6.21-rc7, I noticed that it tried to push a *lot* of objects over ssh. As in:

% git push master
updating 'refs/heads/master'
  from 5a8f676142f0c4714c7820793f58a63d33bf4c2a
  to   e8bea23a40138e4958728dc06b00e9a730456b68
updating 'refs/heads/2.6.21-rc7-ext4-1'
  from 0000000000000000000000000000000000000000
  to   e8bea23a40138e4958728dc06b00e9a730456b68
Generating pack...
Done counting 49509 objects.
Result has 42471 objects.
Deltifying 42471 objects.
 100% (42471/42471) done
Writing 42471 objects.
   9% (3823/42471) done

Ouch. This problem seems to occur locally as well, but I had always ignored it since it wasn't that annoying, and I could always do a "git gc --prune" to get rid of the mess afterwards. It seems that git-receive-pack isn't communicating the fact that there's no need to send objects that can be referenced via the alternates file.

Am I doing something wrong? Is there a better way of dealing with this situation? At this point I'm thinking scp'ing over the 252k pack file, installing it in my git tree on master.kernel.org, and then running "git gc --prune". Is there a better way?

						- Ted

Santi Béjar· Apr 16, 2007, 13:13 UTC · re: Theodore Ts'o · lore

Re: git-receive-pack doesn't understand objects/info/alternates?

On 4/16/07, Theodore Ts'o <tytso@mit.edu> wrote:

>
> When I push a kernel repository to master.kernel.org, where the
> repository only has at most a dozen changes on top of 2.6.21-rc7, I
> noticed that it tried to push a *lot* of objects over ssh.  As in:

This is because git only trusts the the commits in $GIT_DIR/refs. Since commit v1.5.1-107-ge3c6f24 (in next) git-fetch first checks if we have all the objects that we are going to fetch available locally. This could be added for the push. But for now you could add a branch in your repo in master.kernel.org to track linus' master branch.

Santi

Theodore Tso· Apr 16, 2007, 15:30 UTC · re: Santi Béjar · lore

Re: git-receive-pack doesn't understand objects/info/alternates?

On Mon, Apr 16, 2007 at 03:13:25PM +0200, Santi Béjar wrote:

Show 11 quoted lines

> On 4/16/07, Theodore Ts'o <tytso@mit.edu> wrote:
> >
> >When I push a kernel repository to master.kernel.org, where the
> >repository only has at most a dozen changes on top of 2.6.21-rc7, I
> >noticed that it tried to push a *lot* of objects over ssh.  As in:
> 
> This is because git only trusts the the commits in $GIT_DIR/refs.
> Since commit v1.5.1-107-ge3c6f24 (in next) git-fetch first checks if
> we have all the objects that we are going to fetch available locally.
> This could be added for the push. But for now you could add a branch
> in your repo in master.kernel.org to track linus' master branch.

Thanks for the explanation!

So if I add a symlink from .git/refs/heads/kludge to <linus'-tree-on-master>/.git/refs/heads/master this should work as a workaround now, right?

						- Ted

Junio C Hamano· Apr 16, 2007, 17:34 UTC · re: Theodore Tso · lore

Re: git-receive-pack doesn't understand objects/info/alternates?

Theodore Tso <tytso@mit.edu> writes:

Show 18 quoted lines

> On Mon, Apr 16, 2007 at 03:13:25PM +0200, Santi Béjar wrote:
>> On 4/16/07, Theodore Ts'o <tytso@mit.edu> wrote:
>> >
>> >When I push a kernel repository to master.kernel.org, where the
>> >repository only has at most a dozen changes on top of 2.6.21-rc7, I
>> >noticed that it tried to push a *lot* of objects over ssh.  As in:
>> 
>> This is because git only trusts the the commits in $GIT_DIR/refs.
>> Since commit v1.5.1-107-ge3c6f24 (in next) git-fetch first checks if
>> we have all the objects that we are going to fetch available locally.
>> This could be added for the push. But for now you could add a branch
>> in your repo in master.kernel.org to track linus' master branch.
>
> Thanks for the explanation!  
>
> So if I add a symlink from .git/refs/heads/kludge to
> <linus'-tree-on-master>/.git/refs/heads/master this should work as a
> workaround now, right?

Theoretically speaking, not necessarily. Practically speaking it perhaps may.

When Linus runs 'pack-refs --prune', your kludge symlink would not be of any help, as the command removes everything under his linux-2.6.git/refs directory and records the equivalent information in linux-2.6.git/packed-refs file.

        Word of caution.  Symlinking his packed-refs file to
        your repository would not work either.

Theodore Tso· Apr 16, 2007, 18:48 UTC · re: Junio C Hamano · lore

Re: git-receive-pack doesn't understand objects/info/alternates?

On Mon, Apr 16, 2007 at 10:34:18AM -0700, Junio C Hamano wrote:

Show 7 quoted lines

> Theoretically speaking, not necessarily.  Practically speaking
> it perhaps may.
> 
> When Linus runs 'pack-refs --prune', your kludge symlink would
> not be of any help, as the command removes everything under his
> linux-2.6.git/refs directory and records the equivalent
> information in linux-2.6.git/packed-refs file.

Right, but I thought we weren't supposed to do running pack-refs
--prune on master.kernel.org since that would break users using old
git 1.4.x clients and who are accessing the repository over the http
transport.  Or are we not considering that supported anymore on kernel.org?
	
						- Ted

Linus Torvalds· Apr 16, 2007, 18:57 UTC · re: Theodore Tso · lore

Re: git-receive-pack doesn't understand objects/info/alternates?

On Mon, 16 Apr 2007, Theodore Tso wrote:

Show 5 quoted lines

> 
> Right, but I thought we weren't supposed to do running pack-refs
> --prune on master.kernel.org since that would break users using old
> git 1.4.x clients and who are accessing the repository over the http
> transport.

I've been packing refs for many months already..

		Linus