Hi, I like both ideas. I fact I had both my self. Cherry-picking a range can be implemented using a simple shell script. So that is not that important. > I think that would not be possible because of the challenges when > dealing with conflicts. If cherry-picking to a not checkout branch causes conflicts it could be rejected. It's that simple. The use case is: You have many topic-branches. Of course you develop on the big temporary merge. However you want to push your changes to the topic branches. You may be working on multiple topics at the same time. Some of the topics may quick hacks to make a porject work on your system such as patching shebang lines, change PHP require lines etc. Currently you have to git checkout topic1; git cherry-pick big-merge git checkout topic2; git cherry-pick big-merge~2 git checkout big-merge compare this to git cherry-push HEAD topic1 git cherry-push HEAD~2 topic2 not much typing. Very often there are no conflicts and you know that there are none. If you have conflicts you can still fallback going the slow way. Maybe the command could behave this way: git cherry-push-checkout-on-failure hash other-branch I'd be very happy about such a git cherry-push-checkout-on-failure command. I'm not sure whether the command should be renamed. I did so for fun. Marc Weber -- 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