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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 23, 2012, 19:18 UTC
Message-ID: <7v4njcpof8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CANiSa6i0-Z=FkPnSJxgT+3ABHTzgOTNNNUb=wHQpm2DKAN_UOw@mail.gmail.com>

Martin von Zweigbergk <martinvonz@gmail.com> writes:

Show 15 quoted lines

> On Sat, Dec 22, 2012 at 7:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Martin von Zweigbergk <martinvonz@gmail.com> writes:
>>
>>>>From the user's point of view, it seems natural to think that
>>> cherry-picking into an unborn branch should work, so make it work,
>>> with or without --ff.
>>
>> I actually am having a hard time imagining how that could ever be
>> natural.
>
> Fair enough. What's natural is of course very subjective.  ...
> happens to be empty. Of course, pretty much any operation that needs
> more than the tree (indirectly) pointed to by HEAD would fail the
> "whenever possible" clause. I realize that cherry-pick _does_ need the
> current commit to record the parent of the resulting commit,...

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":

    1. Your first commit adds "Makefile" and "hello.c", to build the
       "Hello world" program.

    2. Your second commmit adds "goodbye.c" and modifies "Makefile",
       to add the "Goodbye world" program.

    3. You run "rebase -i --root" to get this insn sheet:

	pick Add Makefile and hello.c for "Hello world"
        pick Add goodbye.c for "Goodbye world"

       and swap them:

        pick Add goodbye.c for "Goodbye world"
	pick Add Makefile and hello.c for "Hello world"

    4. The first one conflicts, as it wants to add new bits in
       "Makefile" that does not exist.  You edit it and make the
       result pretend as if "goodbye.c were the first program you
       added to the project (i.e. adding the common build
       infrastructure bits you did not change from the real first
       commit back to "Makefile", but making sure it does not yet
       mention "hello.c").

    5. "rebase --continue" will give you conflicts for the second
       one too, and your resolution is likely to match the tip
       before you started the whole "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 to be the beginning of the history so its log needs to be adjusted, but "rebase -i" can choose to always make it conflict and force the user to write a correct log message, so it won't expose the fundamental flaw you would add if you allowed the end-user facing "cherry-pick" to pick something to create a new root commit without interaction.

> In the same way, I think "git reset" should work on an unborn branch,
> even though there is no commit that we can be "modifying index and
> working tree to match" (from man page).

I agree that "git reset" without any commit parameter to reset the index and optionally the working tree (with "--hard") should reset from an empty tree when you do not yet have any commit. If HEAD points at an existing commit, its tree is what you reset the contents from. If you do not have any commit yet, by definition that tree is an empty tree.

But I do not think it has anything to do with "cherry-pick to empty", so I do not agree with "In the same way" at all.

> As for use cases, I didn't consider that much more than that it might
> be useful for implementing "git rebase --root". I haven't implemented
> that yet, so I can't say for sure that it will work out.

I think it makes sense only as an internal implementation detail of "rebase -i --root".

> One use case might be to rewrite history by creating an new unborn
> branch and picking the initial commit and a subset of other commits.

If you mean, in the above sample history, to "git cherry-pick" the commit that starts the "Hello world" and then do something else on top of the resulting history, how would that be different from forking from that existing root commit?

> Anyway, I didn't implement it because I thought it would be very
> useful, but mostly because I just thought it should work (for
> completeness).

I would not exactly call X "complete" if X works in one way in most cases and it works in quite a different way in one other case, only because it would have to barf if it wanted to work in the same way as in most cases, and the different behaviour is chosen only because "X that does something is better than X that stops in an impossible situation and barfs".