Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.

From: Yann Dirson <ydirson@altern.org>
Date: May 19, 2006, 20:25 UTC
Message-ID: <20060519202540.GF6535@nowhere.earth>
In-Reply-To: <Pine.LNX.4.64.0605191159520.10823@g5.osdl.org>

On Fri, May 19, 2006 at 12:02:48PM -0700, Linus Torvalds wrote:

Show 26 quoted lines

> 
> 
> On Fri, 19 May 2006, Yann Dirson wrote:
> 
> > On Thu, May 18, 2006 at 03:53:36PM -0700, Junio C Hamano wrote:
> > > Yann Dirson <ydirson@altern.org> writes:
> > > 
> > > > To make my point maybe more clear: if someone really wants to make a
> > > > graft permanent, wouldn't some history rewriting ... be the
> > > > way to go,...
> > > 
> > > Yes.
> > 
> > So if temporary usage is a typical use for grafts, don't we want to
> > protect people using them from pruning ?  I got no feedback to my
> > suggestion of changing the default behaviour, even to say it was a bad
> > idea :)
> 
> I don't actually know how much grafts end up being used. Right now, the 
> only really valid use I know about is to graft together the old kernel 
> history kind of thing, and I suspect not a whole lot of people do that (I 
> keep a separate kernel history tree around for when I need to look at it, 
> and it doesn't happen all that often).
> 
> So I think the lack of feedback on the graft-related issue comes directly 
> from that lack of graft usage.

I take this as an incentive to share my use of the think :)

On several projects managed with CVS, I use a git mirror (maintained with git-cvsimport for now) to prepare my sets of patches with stgit, before committing them to cvs (through git-cvsexportcommit). In this context, since merges are not recorded in cvs, and cvs insists that all branches must derive from the trunk, I use grafts to:

	1. record merges
	2. cause git to believe that the trunk derives from the vendor
	   branch
	3. hide those pseudo revisions cvs adds to rcs files saying
	   "file was initially added to branch foo"

It is the latter use which caused the loss previously mentionned. It could have been avoided by making cvsimport, or more likely cvsps more clever wrt this case.

> We _could_ decide that fsck should just follow the "real parents" and the 
> grafts _both_. That's the safe thing to do by default. Possibly with a 
> flag to say "prefer one over the other", or even a "prefer which-ever 
> exists".

I'm not sure I see how "prefer which-ever exists" would be useful - do you have anything precise in mind ?

Best regards,

-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>