Re: Bug: segfault during git-prune

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 28, 2007, 16:09 UTC
Message-ID: <alpine.LFD.0.98.0706280901580.8675@woody.linux-foundation.org>
In-Reply-To: <alpine.LFD.0.98.0706280844460.8675@woody.linux-foundation.org>

On Thu, 28 Jun 2007, Linus Torvalds wrote:

Show 8 quoted lines

> 
> Yeah, git-fsck knows about subprojects. I bet git-prune just doesn't. 
> 
> And indeed.. Here's a patch for it, but the fact is, you really should 
> *not* prune that repository, because you'll prune away all the subproject 
> data, which you seem to have in the same repo!
> 
> (General rule: never *ever* prune a shared object repository!)

Btw, we could make the "reachable" code say that *if* you have the commit of a subproject in your current object directory, it will follow that commit recursively, and thus sharing an object store at the superproject level is "ok" as far as "git prune" is concerned.

We don't currently even have that kind of function, though. Calling "parse_commit()" will complain very loudly if the commit doesn't exist, but it's actually perfectly fine to not exist if it's in a separate subproject.

So if you actually want to use subprojects *and* prune them, *and* you want to keep all the subproject objects in the same big object database, you'd have to add some commit object "parse-if-you-can-find-it" thing, and use that.

It shouldn't be fundamentally hard, but it's _not_ what my patch did. My patch just says: "subprojects are separate projects, and we don't do reachability from superproject to subproject".

		Linus