Ramkumar Ramachandra wrote:
> So, we're
> really faced with two choices:
> 1. Make this patch enormous by moving as well as refactoring
> everything into a beautiful public API. I suspect this won't be easy
> to review at all.
> 2. Keep this patch as it is, and introduce a future patch to clean up
> the API. This is the approach I was going for.
Well, "beautiful public API" means "just what cmd_cherry_pick and
cmd_revert needs", right? So I'd suggest:
1. Figuring out what functions they need, and doing the minimal
refactoring needed to make them separate functions.
2. As patch #2, moving everything to sequencer.c and exposing those
functions in sequencer.h.
3. In later patches, making changes needed for what "git commit"
needs.
Luckily step (1) is already done. The functions are parse_args()
and pick_revisions() (though they could presumably use less generic
names).
Hmm?
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