Re: .git grows after git-gc?

From: Nicolas Pitre <nico@cam.org>
Date: Apr 24, 2007, 14:00 UTC
Message-ID: <alpine.LFD.0.98.0704240939360.12375@xanadu.home>
In-Reply-To: <200704241431.33624.andyparkins@gmail.com>

On Tue, 24 Apr 2007, Andy Parkins wrote:

Show 8 quoted lines

> 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...

[...]

Show 5 quoted lines

> $ 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