Re: [BUG] multi-commit cherry-pick messes up the order of commits
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Jan 12, 2012, 19:21 UTC
- Message-ID
- <4F0F32CC.8040404@kdbg.org>
- In-Reply-To
- <CALkWK0=Mv_tzNw-hN_9fAr+vABappndEK5iSWQHDk8Yk6Z-stw@mail.gmail.com>
Am 12.01.2012 18:09, schrieb Ramkumar Ramachandra:
Show 12 quoted lines
> @@ -2054,7 +2054,10 @@ int prepare_revision_walk(struct rev_info *revs)
> if (commit) {
> if (!(commit->object.flags & SEEN)) {
> commit->object.flags |= SEEN;
> - commit_list_insert_by_date(commit,
> &revs->commits
> + if (revs->literal_order)
> + commit_list_insert(commit,
> &revs->commits
> + else
> +
> commit_list_insert_by_date(commit, &revs-Why do we need a new flag?
git show origin/master origin/maint git show origin/maint origin/master
show the revisions in different order, in particular, in the order requested on the command line. Shoudn't cherry-pick be able to do the same without new hacks?
-- Hannes