Re: [PATCH v3 1/4] git-cherry-pick: add allow-empty option
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 10, 2012, 20:32 UTC
- Message-ID
- <7v8vi3pbtf.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20120410200019.GC17776@hmsreliant.think-freely.org>
Neil Horman <nhorman@tuxdriver.com> writes:
Show 24 quoted lines
> On Tue, Apr 10, 2012 at 12:32:18PM -0700, Junio C Hamano wrote: >> 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...
Not at all unlikely, especially in a distributed world.
You may have seen two patches but they make sense as one so that you apply to one branch as one change, while the branch you are cherry-picking from may have these two changes as individual commits. Neither of them will apply cleanly to your tree, and your resolution will be "keep mine---I already have this".