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

[A Large Angry SCM <gitzilla@gmail.com>]

Linus Torvalds wrote:
> 
> On Wed, 14 May 2008, Nicolas Pitre wrote:
> 
>> On Wed, 14 May 2008, Linus Torvalds wrote:
>>
>>> Of course, the more aggressively we prune, the more we end up having to 
>>> depend on the fact that a commit that is in a pack that is marked "keep" 
>>> must *always* have everything that leads to it in that pack or others also 
>>> marked "keep". We effectively have that already (because we've always 
>>> pruned away the commits early), but it's a thing to keep in mind whenever 
>>> we prune even more aggressively.
>> I wonder if this is a good thing.  Such a rule would effectively put 
>> restrictions on how objects like big blobs could be distributed amongst 
>> many .keep packs.  I just wish we're not painting ourselves in a corner.
> 
> You can distribute big objects arbitrarily among many .keep packs, but 
> what you can *NOT* do (and which has _always_ been a bug to do) is to have 
> a *.keep pack that refers to objects that are not in a .keep pack!
> 
> So keep<->keep you can do anything you want, and distribute objects any 
> way.
> 
> But a keep pack must only refer to objects in itself or in other keep 
> packs.
> 
> Because otherwise, if we ever hit an object in a keep pack, we'll stop 
> even looking further when we use --unpacked. And that has always been true 
> (admittedly only for "commit" objects, but those are the ones that most 
> commonly refer to other objects, so ..)

Sounds like git-fsck needs to start checking for this.