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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html