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

[Junio C Hamano <gitster@pobox.com>]

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.

When you are on an unborn branch, you may have some files in your
working tree, and some of them may even be registered to the index,
but the index is merely for your convenience to create your first
commit, and as far as the history is concered, it does not matter.

By definition you do not have any history in such a state.  What
does it even mean to "cherry-pick" another commit, especially
without the --no-commit option?  The resulting commit will carry the
message taken from the original commit, but does what it says match
what you have done?

I can understand that it may sometimes make sense to do

  $ git show --diff-filter=A $that_commit | git apply

as a way to further update the uncommitted state you have in the
working tree, so I can sort of buy that --no-commit case might make
some sense (but if you make a commit after "cherry-pick --no-commit",
you still get the log message from that commit, which does not
explain the other things you have in your working tree) in a limited
situation.

It seems to me that the only case that may make sense is to grab the
contents from an existing tree, which might be better served with

  $ git checkout $that_commit -- $these_paths_I_am_interested_in

> Cherry-picking anything other than a commit that only adds files, will
> naturally result in conflicts. Similarly, revert also works, but will
> result in conflicts unless the specified revision only deletes files.

You may be able to make it "work" for some definition of "work", but
I am not sure how useful it is.

Puzzled...