Re: Bug: segfault during git-prune

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 28, 2007, 22:31 UTC
Message-ID: <alpine.LFD.0.98.0706281525460.8675@woody.linux-foundation.org>
In-Reply-To: <200706282321.44244.andyparkins@gmail.com>

On Thu, 28 Jun 2007, Andy Parkins wrote:

Show 6 quoted lines

> 
> I had hoped that git-prune wouldn't be a risk because I have:
> 
>  * -- * -- * -- * -- * (ffmpeg-svn)
> 
>       * -- * -- * -- * (libswscale-svn)

Ok. If all subproject branches are also visible in the superproject as refs, then "git prune" should work fine, and you can apply my patch and it should just work very naturally: the reachability analysis will find the subprojects not through the superproject link, but simply through the direct refs to the subproject.

> > (General rule: never *ever* prune a shared object repository!)
> 
> Even when I'm sure that every object of interest is behind a head ref?

So yes, in that case, you're ok.

This is not unlike just having two different repositories sharing the same object directory: as long as the two different repositories both have the appropriate refs, pruning is fine. In other words, you can see them as just independent branches in the same repo.

And in fact, subprojects are obviously very much *designed* to work that way: a subproject is basically a "different repository". So the basic rule is that if it would work with totally independent repos, it works with subprojects.

[ That's all aside from the kind of bug that you found, where some code 
  that parses the tree structures hadn't been updated for subprojects, of 
  course ]

Anyway, if that patch works for you, I'd suggest you just pass it on to Junio (and feel free to add my "Signed-off-by:" on it - but conditional on you having actually tested it).

		Linus