Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> No, read the message again and think for 5 minutes.
>
> pick abcdefg
> pick pqrstuv
>
> Now imagine that pqrstuv is a unique commit name _before_ cherry-picking
> abcdefg, but not _after_ it. Unlikely? Yes. Impossible? No.
No, I am still being misunderstood. That is not the uniqueness issue I
was talking about.
As I tried to describe in a message that used a phrase "the beauty of your
approach" (which I suspect you stopped reading after that phrase), your
rule "an object name names the commit after the last operation that used
the commit, unless it is the first appearance in the sequence, in which
case it names the original commit" works most of the time, but becomes
cumbersome and unwieldy when the history you try to reproduce becomes more
elaborate. And the reason I suggested 'mark' was because I was seeing
this in the context of the sequencer, not just "rebase -i".
This is just a minor syntax issue and I am not sure why we got into this
misunderstanding, but let's try again. Suppose you want to recreate this
history on top of a different O'. For merges, upper parents are earlier
ones:
A reset O'
/ \ pick B
/ X reset O'
/ / \ pick A
O---B Z merge B -- recreate X
\ \ / reset O'
\ Y pick C
\ / merge B? -- recreate Y
C reset B -- go back to recreated X
merge B? -- recreate Z
The above sequence does not work. As you already used B to create X',
when you want to recreate Y, the last operation used B is now X' and you
cannot name B' to merge that to C' to produce Y' (and the above sequence
is wrong in that it attempts to recreate Y' in a wrong order --- we should
reset to the recreated B and merge recreated C to produce Y', but for that
you need to be able to say "reset to B'", but you've already used B to
recreate X' so you cannot do that).
You could (because you are intelligent human) reorder things to take
advantage of the fact that pick and merge uses the "current detached HEAD"
to avoid refering to B in this particular case, like this:
reset O'
pick A
reset O'
pick B
reset O'
pick C
reset B -- go back to recreated B
merge C -- recreate Y
reset A -- go back to recreated A
merge B -- recreate X
merge C -- recreate Z
But I think the only reason you can do this in this case is because B is
used only twice. If you have a history where rewritten B itself (not the
result of applying/merging the rewritten B) needs to be used more than
twice as the second or later merge parent, I do not think you would have a
way to name that rewritten B for the later uses.
I may be mistaken and you may even be able to prove that there is always a
way to recreate any shape of history by reordering insns and still using
your rule, but the point is that the insn sequence needs to be prepared by
tools (i.e. frontends for the sequencer), and I do not want to make the
life of people who are writing the frontends any harder than necessary.
The syntax and semantics that uses 'mark' avoids this unwieldiness by
making the rule much simpler.
* Operation operates on the current detached HEAD (as in your rule)
* A commit object name always names _that_ commit object.
* If you need to name an intermediate result, you 'mark' it.
--
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
