Re: Why repository grows after "git gc"? / Purpose of *.keep files?

From: Teemu Likonen <tlikonen@iki.fi>
Date: May 12, 2008, 20:24 UTC
Message-ID: <20080512202414.GA8620@mithlond.arda.local>
In-Reply-To: <alpine.LFD.1.10.0805121527550.23581@xanadu.home>

Nicolas Pitre wrote (2008-05-12 15:36 -0400):

Show 8 quoted lines

> On Mon, 12 May 2008, Teemu Likonen wrote:
> 
> > > On Mon, 12 May 2008, Teemu Likonen wrote:
> > > 
> > > > Well, I don't really have any problems with the current
> > > > behaviour; it just feels a bit strange that, for example,
> > > > Linus's kernel repository grew about 90MB after just one update
> > > > pull and gc.

Show 9 quoted lines

> > As I used the kernel repo just for testing this behaviour in
> > question I did both things today. Timestamps tell that there were
> > six hours between the initial .keep pack and the new pack created by
> > manual "git gc".
> 
> This is way too big a difference.  Something is going on.
> 
> What git version is this? And can you send me the content of your
> .git/logs directory?

I'm using Git from the "master" branch; compiled it today. I have the following gc/repack-related patches applied from the "pu" branch:

  builtin-gc.c: deprecate --prune, it now really has no effect
  git-gc: always use -A when manually repacking
  repack: modify behavior of -A option to leave unreferenced objects unpacked

But I have experienced the same earlier with some other post-1.5.5 version so I believe you can reproduce this yourself. After cloning Linus's linux-2.6 repo its .git directory weights 209MB. After single "git pull" and "git gc" it was 298MB in my test.

I'll send you the .git/logs directory but I'm afraid it doesn't tell much. There are just three files:

  .git/logs/HEAD
  .git/logs/refs/heads/master
  .git/logs/refs/remotes/origin/master

They containt one line for the initial clone and one line for the fast-forward pull.

Show 10 quoted lines

> > I think it can contain at some later point. For example, if a user
> > first fetches all the branches but later decides to track only one
> > branch. After deleting unneeded tracking branches and expiring the
> > reflog there'll be dangling objects in the original .keep pack
> > created with "git clone".
> 
> Sure.  But to decide to track only one branch and exclude the others
> require some higher level of git knowledge already.  At that point if
> you really care about top packing performances you certainly can deal
> with the .keep file as well.

Perhaps so. Although I don't consider this very high level Git knowledge:

  $ git remote rm origin
  $ git remote add -t wanted_branch origin git://...

The first command removes all the tracking branches. The latter starts to track only one branch.