On Tue, 24 Apr 2007, Andy Parkins wrote:

quoted text
> 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...
[...]
quoted text
> $ du -h .git
> 95M     .git
> 
> $ git-gc --prune
> Generating pack...
[...]
quoted text
> $ 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html