Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
