Re: [PATCH v3 1/4] git-cherry-pick: add allow-empty option
- From
Neil Horman <nhorman@tuxdriver.com>
- Date
- Apr 10, 2012, 20:00 UTC
- Message-ID
- <20120410200019.GC17776@hmsreliant.think-freely.org>
- In-Reply-To
- <7vfwcbpem5.fsf@alter.siamese.dyndns.org>
On Tue, Apr 10, 2012 at 12:32:18PM -0700, Junio C Hamano wrote:
Show 20 quoted lines
> Neil Horman <nhorman@tuxdriver.com> writes: > > > On Tue, Apr 10, 2012 at 09:45:46AM -0700, Junio C Hamano wrote: > > ... > >> (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