From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 03 Jul 2008 22:51:03 GMT
Subject: Re: [RFC/PATCH 1/4] Add git-sequencer shell prototype
Message-ID: <7vbq1ey42w.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0807031142540.9925@racer>

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.