Neil Horman [off-list ref] writes:
On Tue, Apr 10, 2012 at 09:45:46AM -0700, Junio C Hamano wrote:
...
quoted
(2) The message is given by the "git commit" command. "If the commit was
created empty" looks confusing. Even though I can understand that
Its coded within the git commit command code, but is only ever displayed if
whence is GIT_CHERRY_PICK, so as far as I can see, from a users perspective,
this will only be seen if they type git cherry-pick on the command line.
Here is what I tried, and I think you are wrong.
$ git cherry-pick $some_commit
... conflicts ...
$ edit so that the working tree matches HEAD
$ git commit -a
... message from status ...
THE ADVICE IN QUEWSTION COMES HERE!!!
On Tue, Apr 10, 2012 at 12:32:18PM -0700, Junio C Hamano wrote:
Neil Horman [off-list ref] writes:
quoted
On Tue, Apr 10, 2012 at 09:45:46AM -0700, Junio C Hamano wrote:
...
quoted
(2) The message is given by the "git commit" command. "If the commit was
created empty" looks confusing. Even though I can understand that
Its coded within the git commit command code, but is only ever displayed if
whence is GIT_CHERRY_PICK, so as far as I can see, from a users perspective,
this will only be seen if they type git cherry-pick on the command line.
Here is what I tried, and I think you are wrong.
$ git cherry-pick $some_commit
... conflicts ...
$ edit so that the working tree matches HEAD
$ git commit -a
... message from status ...
THE ADVICE IN QUEWSTION COMES HERE!!!
Ok, I admit I didn't really think of that case, but that seems to me to be the
trivial case, which is unlikely to be encountered. If you do a git cherry-pick and
have conflicts, you by definition don't have a commit that is resolved to empty
(at least not without manual intervention), nor do you have a commit which was
initially empty. You really have to go out of your way to take a commit that
conflicts, make it empty, and then commit it without realizing that its empty.
I agree that seeing advice regarding git cherry-pick when you run git commit is
awkward, but its no worse than seeing advice indicating you should run git
commit when you run git cherry-pick (i.e. the case in which you run git
cherry-pick <C>, where <C> is empty an not fast-forward-able.
Perhaps whats called for here is and advice differentiator? I.e if git commit
is run directly from the command line, issue advice relating to using git commit
--allow-empty, otherwise issue advice relating to git cherry-pick.
I think we could do that by looking at the parent process at run time, unless
theres a good way to differentiate by the sate information in .git
Thoughts?
Neil