On Sat, Dec 22, 2012 at 7:24 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. Fair enough. What's natural is of course very subjective. In my opinion, whenever possible, operations on an unborn branch should behave exactly as they would on an arbitrary commit whose tree just 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, but that almost seems like an implementation detail, i.e whether we're adding a parent or adding no parent (when on unborn branch) to the list of parents. 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 think many users, like me, think of unborn branches as having an empty tree, rather than being a special state before history is created. Sure, such thinking is not technically correct, but it still seems to be some people's intuition (including mine). >> 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. 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. 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. 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 could resend as part of my rebase series (called mz/rebase-range at some point) once that's done. Then we can discuss another solution in the scope of that series if we don't agree on allowing on cherry-pick on an unborn branch. Btw, I have another series, which I'll send after 1.8.1, that teaches "git reset" to work on an unborn branch (among other things). We might want to decide to support both or neither of the commands on an unborn branch. On Sat, Dec 22, 2012 at 7:24 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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