Martin von Zweigbergk [off-list ref] writes:
quoted
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...
On Sat, Dec 22, 2012 at 7:24 PM, Junio C Hamano [off-list ref] wrote:
Martin von Zweigbergk [off-list ref] writes:
quoted
quoted
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).
quoted
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 [off-list ref] wrote:
Martin von Zweigbergk [off-list ref] writes:
quoted
quoted
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
quoted
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...
On Sun, Dec 23, 2012 at 7:24 AM, Martin von Zweigbergk
[off-list ref] wrote:
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 agree that it would be nice if it worked.
Thanks,
Christian.