Re: [RFC/PATCH 1/4] Add git-sequencer shell prototype

Johannes Schindelin [off-list ref] writes:

quoted

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.

quoted

 (2) When $what is revert, this codepath shouldn't be exercised, should 
 it?

Yes.

quoted

 (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.