Hi, Jonathan Nieder writes: > Ramkumar Ramachandra wrote: >> Currently, revert_or_cherry_pick does too many things including >> argument parsing and setting up to pick the commits; this doesn't make >> a good API. > > On the contrary, generally speaking single-call APIs are often very > pleasant to work with. [...] > So this is probably not about the function doing too many things but > something else. Took me some time to figure this out. I suppose I could also phrase this as "prepare to make revert_or_cherry_pick the starting point for continuing in future", but it might result in a huge explanation about what continuing means, and why continuing won't need to do argument parsing. I think I'll put in a more superficial intent (Justified because I like this change even if we never support continuing in the future). New commit message. revert: Separate cmdline parsing from functional code Currently, revert_or_cherry_pick sets up a default git config, parses command-line arguments, before preparing to pick commits. This makes for a bad API as the central worry of callers is to assert whether or not a conflict occured while cherry picking. The current API is like: if (revert_or_cherry_pick(argc, argv, opts) < 0) print "Something failed, I'm not sure what" Simplify and rename revert_or_cherry_pick to pick_commits so that it only has the responsibility of setting up the revision walker and picking commits in a loop. Transfer the remaining work to its callers. Now, the API is simplified as: if (parse_args(argc, argv, opts) < 0) print "Can't parse arguments" if (pick_commits(opts) < 0) print "Something in the picking mechanism failed" Later in the series, pick_commits will serve as the starting point for continuing a cherry-pick or revert. -- Ram -- 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