From: Johannes Sixt <j.sixt@viscovery.net>
Date: Wed, 30 Apr 2008 10:29:34 GMT
Subject: Re: [PATCH v2 04/13] Teach rebase interactive the mark command
Message-ID: <48184A0E.3050704@viscovery.net>
In-Reply-To: <7vr6cn1yzk.fsf@gitster.siamese.dyndns.org>

Junio C Hamano schrieb:
> In the context of "rebase -i", this may not be a problem, but by forcing
> us to name commits always with original commits, we cannot build (instead
> of rebuild) a history that does not yet exist using the sequencer
> machinery, can we?
> 
> If we want to transplant "^C ^N O" in this history elsewhere:
> 
>       --o---C---N
>                / 
>           B---M
>          /   /
>         O---A
> 
> while inserting a new fix-up commit F on top of B before we merge that
> side branch to rewritten A:
> 
>               --o---C---N'
>                        / 
>               B'--X---M'
>              /       /
>         O---Q-------A'
> 
> Would/Should the machinery somehow figure out that the merge between the
> rewritten A (which is A') and an inserted commit X (which is made on top
> of the rewritten B) corresponds to M in the original history?

No. The 'merge' insn tells the original merge commit. So, rebase would
suggest this todo list:

	pick B
	reset Q
	pick A
	merge M A B
	merge N M C

and you would have to change it to

	pick B
	pick X       <--
	reset Q
	pick A
	merge M A X  <--
	merge N M C

But you could just as well do this:

	edit B       <--
	reset Q
	pick A
	merge M A B
	merge N M C

When the 'edit B' stops, HEAD is at B'. Now you git-am X, then 'rebase
--continue'. Since now HEAD is at X, X is recorded as the rewritten
version of B, and the 'merge M A B' would pick X as the second parent.

-- Hannes