From: Junio C Hamano Date: Tue, 10 Apr 2012 20:32:44 GMT Subject: Re: [PATCH v3 1/4] git-cherry-pick: add allow-empty option Message-ID: <7v8vi3pbtf.fsf@alter.siamese.dyndns.org> In-Reply-To: <20120410200019.GC17776@hmsreliant.think-freely.org> Neil Horman writes: > On Tue, Apr 10, 2012 at 12:32:18PM -0700, Junio C Hamano wrote: >> Neil Horman 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".