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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html