Re: [PATCH 2/2] learn to pick/revert into unborn branch

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 23, 2012, 19:35 UTC
Message-ID: <7vvcbso93f.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7v4njcpof8.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 10 quoted lines

> Yes, and I do not think it is an implementation detail.
>
> I am not opposed to an "internal use" of the cherry-pick machinery to
> implement a corner case of "rebase -i":
> ...
> In step 4., you would be internally using the cherry-pick machinery
> to implement the step of "rebase -i" sequence.  That is what I would
> call an implementation detail.  And that is cherry-picking to the
> root.  It transplants something that used to depend on the entire
> history behind it ...

Just to add another example, I do not think I would be opposed to the case where you "edit" the root commit in the above example, i.e. keeping the "Hello world" as the root commit, but modifying its tree and/or log message. The internal impemenation detail has to first chery-pick that existing commit on top of a void state before it gives the user a chance to tweak the tree and commit the result with a modified log message. Just like "commit --amend" can be used to amend the root commit, it logically makes sense the recreated commit records nothing as its parent if done when HEAD is not valid yet.