.git grows after git-gc?

Hello,

Not important at all, but I was surprised to see this:

$ git fetch \
   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git \
   refs/heads/master:refs/remotes/vendor
remote: Generating pack...
remote: Done counting 194409 objects.
remote: Deltifying 194409 objects.
remote:  100% (194409/194409) done
Indexing 194409 objects.
remote: Total 194409 (delta 147074), reused 179896 (delta 138737)
 100% (194409/194409) done
Resolving 147074 deltas.
 100% (147074/147074) done
* refs/remotes/vendor: storing branch 'master' of 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y
  commit: 7a715c6

$ du -h .git
95M     .git

$ git-gc --prune
Generating pack...
Done counting 194520 objects.
Deltifying 194520 objects...
 100% (194520/194520) done
Writing 194520 objects...
 100% (194520/194520) done
Total 194520 (delta 147074), reused 194520 (delta 147074)
Pack pack-220cec9989ebd8b75963de71742861c6adbeda7d created.
Removing unused objects 100%...
Done.

$ du -h .git
97M     .git

That's a bit odd isn't it?



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

On Tue, 24 Apr 2007, Andy Parkins wrote:

Hello,

Not important at all, but I was surprised to see this:

$ git fetch \
   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git \
   refs/heads/master:refs/remotes/vendor
remote: Generating pack...

[...]

$ du -h .git
95M     .git

$ git-gc --prune
Generating pack...

[...]

$ du -h .git
97M     .git

That's a bit odd isn't it?

Two possible explanations:

1) I recently fixed pack-objects which didn't respect the delta depth
   limit when fetching. See commit  898b14cedc for details. This could 
   potentially cause some repacks to create slightly larger packs.

2) When fetching a pack, the client sends its capabilities to the server 
   who can alter some packing parameters accordingly.  One such 
   parameter is --delta-base-offset which your client most certainly 
   supports.  This means that the packs you receive and keep as is in 
   your local repo were encoded with --delta-base-offset for maximum 
   network efficiency.

   Now when you repack, this parameter won't be used by default unless 
   you have repack.usedeltabaseoffset set to true in your config, which 
   will cause a small increase in pack size.

I think that (2) is the most probable cause of repack growth in your 
case.  Just try:

	git config --global repack.usedeltabaseoffset true
	git gc

and you should get that 2MB back, possibly a bit more.


Nicolas

On Tuesday 2007 April 24, Nicolas Pitre wrote:

Thank you for your thorough explanation.

   Now when you repack, this parameter won't be used by default unless
   you have repack.usedeltabaseoffset set to true in your config, which
   will cause a small increase in pack size.

That sounds like it could easily be it.  I thought I had usedeltabaseoffset 
turned on ages ago; but it turns out (while investigating this strange 
behaviour) what I actually had turned on was "usedelatabaseoffset".

Doh!

I think that (2) is the most probable cause of repack growth in your
case.  Just try:

	git config --global repack.usedeltabaseoffset true
	git gc

and you should get that 2MB back, possibly a bit more.

Strangely enough - I didn't - stayed at 97MB.  It's probably (1) then.

Thanks for your time.  You've helped me find a typo in my config even if I 
didn't get my 2MB back :-)


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

On Tue, 24 Apr 2007, Andy Parkins wrote:

quoted

I think that (2) is the most probable cause of repack growth in your
case.  Just try:

	git config --global repack.usedeltabaseoffset true
	git gc

and you should get that 2MB back, possibly a bit more.

Strangely enough - I didn't - stayed at 97MB.  It's probably (1) then.

Well... to be sure, also try:

	git config --global repack.usedeltabaseoffset false
	git gc

and verify that the repository actually grew.  If it stays the same then 
something is not right.


Nicolas