Re: [PATCH v2 04/13] Teach rebase interactive the mark command

Hi,

On Tue, 29 Apr 2008, Junio C Hamano wrote:

                 A
                / \
               /   X
              /   / \
             O---B   Z
              \   \ /
               \   Y
                \ /
                 C

            X = checkout A, merge B
            Y = checkout C, merge B
            Z = checkout X, merge Y

I start from Q, create A', B' and C' with:

	reset Q
	pick A
        reset Q
        pick B
        reset Q
        pick C

Then I can recreate X by doing

	reset A
        merge B

The problem I had was to figure out the way to go back to "rewritten X". 
I assumed you would say "B" because that is the last insn in the 
sequence that used that name.

But instead you are thinking of letting me just say "X", and somehow 
make the machinery guess by noticing "Ah, original X is a merge between 
original A and B, and we have a merge between rewritten A and rewritten 
B, so we will treat that merge as rewritten "X"?

I actually was hoping we could avoid that, which feels messy.

I cannot bring myself to feel that this is messy.  The more I think about 
it, the clearer it becomes for me that the pick call should use the 
original commit, whereas the merge call should use the rewritten commit 
(and should therefore only be called when all ancestors of that merge 
which need rebasing were rebased already).

BTW I think that I made a stupid mistake in one of my previous mails: when 
I wrote an example for the "merge" command (as I would like it), I did 
_not_ list the original commit name of that merge.  I.e.

	merge <parent2> <parent3>... <message>

I completely forgot that for the $DOTEST/rewritten/ to work, the original 
commit name of that merge has to be listed.

But this got me thinking, and I think that to leave out the first parent 
was another mistake I made, so I really would like to have this syntax:

	merge <orig-commit> <parent1> <parent2>... <message>

This would allow to change the parents in the interactive rebase, and if 
<parent1> is not the current commit at that point, it would implicitly 
call "reset".

What appeals to me is the simplicity of this approach: you refer to the 
commits by calling them by their (original) name.

In the (probably really rare) occasion that you really need to refer to an 
original _and_ a rewritten commit, you can always use _any_ commit-ish as 
argument to the command.

Ciao,
Dscho