Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> On Tue, 22 Apr 2008, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
