Martin von Zweigbergk <martinvonz@xxxxxxxxx> 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... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html