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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 3, 2008, 22:51 UTC
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:

Show 20 quoted lines

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