Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 2/4] revisions passed to cherry-pick should be in "default" order

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:54:28

Martin von Zweigbergk [off-list ref] writes:
By the way, I can see the usefulness of --reverse when giving a range,
but I think it's a little confusing when not giving a range.
"git rev-list --reverse --root v1.0.0" is a way to say "give me a
list of commits to be replayed in sequence" without having a bottom,
no?

Ah, you mean when we do _not_ walk.

Yeah, that is why I said that when we do not walk, we should not
even call into prepare_revision_walk() in the first place in my
earlier message.  We should take the commits as given from the
revs->pending.objects list instead.

With your "no_walk = NO_WALK_UNSORTED", calling prepare_revision_walk()
would amont to the same thing, as you would not sort the commits and
use them as given by the user.
So "git cherry-pick A B" will apply B first, then A.
I am confused a bit.  Are you describing a buggy behaviour in the
current codebase, or are you saying we should fix it to behave that
way?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help