Hi Ram, Ramkumar Ramachandra wrote: > Are you certain about pick_revisions? I've copied over the function > here for your reference. My issue is that it's too specific > cherry-pick/ revert: I'm a very pragmatic person: as long as the code and history are readable and behave reasonably well, I'm happy. So in this particular case, why not expose pick_revisions, with some name like revert_or_cherry_pick? It would be readable and behave reasonably well. :) A theoretical other caller could save a fork by calling revert_or_cherry_pick instead of forking a subprocess to do the same. [...] > 2. You mentioned multiple entry points earlier, and that's something > I've been meaning to do: In the long run Sure, and that still seems like a good idea in the long run. But as long as we are not closing doors, ideas about the long run should not get in the way of getting work done today. Hoping that is clearer. Jonathan -- 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