Re: [PATCH/RFC 01/10] Teach rebase interactive the mark command

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 15, 2008, 00:11 UTC
Message-ID: <7vve2k6kpo.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0804141506270.28504@racer>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 11 quoted lines

> I would like it much better, if there was something like
>
> pick 5cc8f37 (init: show "Reinit" message even in ...)
> pick 18d077c (quiltimport: fix misquoting of parse...)
> merge 9876543:5cc8f37,18d077c (Merge blub)
> reset 5cc8f37
> ...
>
> I.e. like with filter-branch, and like with rebase -i -p in its current 
> form, we take the _original_ names as keys as to which commits to merge, 
> or where to reset to.

While the need probably would not be felt strongly if we design this only for rebase -i, I suspect that you would want to have two kinds of reset if you go that route. There might be some other insn that may have similar issues.

For example, imagine a case where you want to create a merge with a recontructed side branch. First you grow the branch you would merge into, with a sequence:

	pick A
        pick B
        pick C

Then in order to reconstruct a side branch that begins from a known point, say the tip of "master", you would want to reset to a commit that is outside of the scope of this rewriting. And then you rebuild that side branch:

	reset master
        pick D
        pick E

And finally (and this step shows the beauty of your approach), come back to the other tip and make the merge:

	reset C
        merge E

Two resets above would have different semantics. The former resets to unwritten, and the latter rewritten.