From: "Junio C Hamano" <gitster@xxxxxxxxx> Sent: Sunday, December 23,
2012 3:24 AM
Subject: Re: [PATCH 2/2] learn to pick/revert into unborn branch
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?
From: "Junio C Hamano" Sent: Sunday, December 23, 2012 7:20 PM
Subject: Re: [PATCH 2/2] learn to pick/revert into unborn branch
Christian Couder <christian.couder@xxxxxxxxx> writes:
I agree that it would be nice if it worked.
That is not saying anything.
Yes, it would be nice if everything worked. But the question in the
thread is "with what definition of 'work'?"
--
From the dumb user perspective, I would have thought that the first
commit to be cherry picked for an unborn branch would be the complete
commit, which is then planted as the branch's start commit. We tend to
talk of cherry picking commits, though the documentation does say 'the
changes introduced', which allows such a (mistaken) user perspective for
this particular case.
It is only in retrospect, and a bit of extra thought, that one could see
that the commit's message would not actually describe the new situation
and should have been edited.
That doesn't mean that it would be right to allow such an initilisation
of an unborn branch, it's more an explanation of how the idea may have
developed.
Philip
--
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