Re: [PATCH] rebase -i: remove CHERRY_PICK_HEAD when cherry-pick failed
- From
- Andrew Wong <andrew.w@sohovfx.com>
- Date
- Apr 4, 2012, 19:23 UTC
- Message-ID
- <4F7C9FAE.5050806@sohovfx.com>
- In-Reply-To
- <20120404181148.GB16993@burratino>
On 04/04/2012 02:11 PM, Jonathan Nieder wrote:
> Do you mean we should get rid of CHERRY_PICK_HELP? >
No. I thought you meant that if "cherry-pick" runs into an error, it should not leave behind a state (i.e. CHERRY_PICK_HEAD) when CHERRY_PICK_HELP is defined. And I was arguing that defining CHERRY_PICK_HELP shouldn't affect the behavior of "cherry-pick" at all. So it shouldn't be trying to remove the state in the first place. The cleanup responsibility should fall into caller of "cherry-pick". i.e. "rebase -i"
Though I now think that my original patch description could be improved to better reflect that.
And you also mention earlier that the patch is more of a symptom relief, and that
> a more appropriate long-term fix would involve "git > cherry-pick" noticing when a patch has resolved to nothing instead of > leaving it to "git commit" to detect that.
And I was arguing that "cherry-pick" doesn't have to detect scenarios where "commit" could fail. Since there could be other scenarios where "commit" could fail and "cherry-pick" is already handling "commit" failing, I think there's no need for "cherry-pick" to handle an empty commit specifically.
So if the list or Junio thinks that the patch is the right thing to do, I should improve on the patch description before we queue it.