Junio C Hamano wrote: > Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > >> What are your thoughts on making it a flag in the revision API to be >> activated with "cherry-pick --literal-order commit1 commit3 commit2" >> or similar? > > That is an insane UI for the sake of flexibility. > > You should be able to look at revs->cmdline and tell if you need to let > cherry-pick walk (i.e. "cherry-pick master..next"), or if the user wants > individual commits (i.e. "cherry-pick A B C"). > > And you do prepare_revision_walk() only when you need to walk; otherwise > you use the contents of revs->pending in order. Okay, just to make sure I understand this correctly: if more than one argument is literally specified, I should not set up the revision walker and pick the commits listed in revs->pending, correct? Then, when I encounter the following command, $ git cherry-pick maint ^master I should just pick two commits: maint, and ^master. But won't this introduce some kind of regression for those who expect me to pick the master..maint range instead? Has this double-interpretation issue come up in other commands? Have we documented this somewhere? Thanks. -- 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