Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> When the history looks like ---A---B and we are at A, cherry-picking B can
>> be optimized to just advancing to B, but that optimization has a slight
>> difference (or two) in the semantics.
>>
>> (1) The committer information would not record the user and time of the
>> sequencer operation, which actually may be a good thing.
>
> This is debatable. But I think you are correct, for all the same reasons
> why a merge can result in a fast-forward.
>
>> (2) When $what is revert, this codepath shouldn't be exercised, should
>> it?
>
> Yes.
>
>> (3) If B is a merge, even if $what is pick, this codepath shouldn't be
>> exercised, should it?
>
> I think it should, again for the same reason why a merge can result in a
> fast-forward.
Sorry, I disagree. "cherry-pick" when this optimization is not applicable
always creates a single parent commit. If the original history looks like:
D---A---B---C
/
M
and when you are cherry-picking B, the above logic would make the result a
merge if you happen to be at A but if you are working elsewhere (perhaps C
or D, or "rewritten A") the result will become a single-parent commit. I
do not see the justification behind such an unreliable/unpredictable
result, from the end-user's point of view.
I like the check and avoidance of creating a commit that will anyway have
the same parent and the same tree as an _optimization_. Making the result
of "cherry-pick B" a merge or a non-merge however is not an optimization;
it is changing semantics.
--
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
