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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 29, 2008, 00:25 UTC
Message-ID: <7v3ap5a4ny.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0804221810180.4460@eeepc-johanness>

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

Show 12 quoted lines

> On Tue, 22 Apr 2008, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> > So I really hate the idea of introducing yet other marks when we already 
>> > have unique identifiers: the (abbreviated) commit names.
>> 
>> Didn't I give you an example why commit object names are _not_ unique
>> identifiers already?
>
> By that reasoning, rebase -i cannot work anyway: it relies on the 
> abbreviated identifiers, not on anything else, for the "pick" command.

No, read the message again and think for 5 minutes.

Picking the same commit twice does not make any sense, neither does picking the resulting commit from an earlier operation in the same sequencer run. Which means that the commit object name for 'pick' can mean _only_ the pre-rewritten commit object, not 'the result of an earlier operation that used that commit'. And you always pick on top of the current (detached) HEAD.

Reset is different. You can reset either to the named commit to start building from a known state that existed before the sequencer run started, or reset to the result of pick (or merge) of the named commit, and your proposal breaks down here, because you cannot tell between the two.

To rebuild this history on top of a commit O' elsewhere:

        O---A---B
             \   \
              D---E---F---G
                         / 
                        X

you would need to:

	pick A
        pick B
        reset <<to the state after "pick A">>
        pick D
        merge <<the state after "pick B">>
        pick F
        merge X (taken from somebody else)

and the syntax proposed to express <<the above part>> can either be your "the result of the last operation that used the named commit", which is simple in some cases, or "named commit, be it with mark or standard sha-1 expression".

Introducing a 'mark' insn to mark the previous result you may want to go back to is one way to solve this without ambiguity. Then abbreviated object name won't have to be mapped as in your proposal.