From: A Large Angry SCM Date: Wed, 14 May 2008 23:24:01 GMT Subject: Re: Why repository grows after "git gc"? / Purpose of *.keep files? Message-ID: <482B7491.30608@gmail.com> In-Reply-To: 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.