Re: [BUG] multi-commit cherry-pick messes up the order of commits
- From
Ramkumar Ramachandra <artagnon@gmail.com>
- Date
- Jan 12, 2012, 19:25 UTC
- Message-ID
- <CALkWK0kk0mVNaetr=triuVYva7inyx2aZvam81qTVA9=Q=UzGw@mail.gmail.com>
- In-Reply-To
- <7vaa5s3hiq.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 14 quoted lines
> Ramkumar Ramachandra <artagnon@gmail.com> 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