Re: Bug: segfault during git-prune

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 28 Jun 2007, Linus Torvalds wrote:
> 
> 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