Re: grafts+repack+prune = history at danger

From: Johannes Sixt <j.sixt@eudaptics.com>
Date: Jan 26, 2007, 09:48 UTC
Message-ID: <45B9CE56.D16DFC81@eudaptics.com>
In-Reply-To: <7vzm86yw0q.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 13 quoted lines

> 
> Johannes Sixt <J.Sixt@eudaptics.com> writes:
> 
> > Here's my stance on it. Grafts should be a local matter. And they alter
> > the world view, with a pronounciation on *view*. That's why I proposed
> > that only log familiy of commands obey them[*]. And probably rev-list so
> > that gitk et.al. have a way to obey them. And also the ref parser (so
> > that master~20 is what it looks it is). Everything else should disregard
> > grafts: repack, prune, fetch, <transfer>-pack, push etc. No nasty side
> > effects anymore.
> 
> I said you are not agreeing, but I should have said you are not
> understanding.

Oh, I think I understand very well. It may just be that I cannot express myself that well ;)

I propose that grafts are only about *view*, not database integrity.

There are no tools that manipulate grafts, that would stop the user to make some blunder; the user has to edit the file *manually*. It is wrong, wrong, wrong to let such a file dictate database integrity.

> grafts can bring otherwise disconnected commits into the
> altered history, so if you want your log to honor grafts, your
> prune and repack need to be aware of them lest you would not
> lose them.

Sure, if I connect my linux repo with a graft to the historical BK tree,
then toss the ref that pointed to the historical tree, then git prune:
- then currently it won't prune the historical tree
- but under my proposal it would. Silly me. Why did I remove that ref?

-- Hannes