Kevin Ballard <kevin@xxxxxx> writes: > It almost works, but not quite. My inclination is to say > `git rev-list --no-walk A B C` should emit A B C in that order. Implemented > this way, `git rev-list --no-walk ^HEAD~3 HEAD` emits commits in the wrong > order, "git rev-list --no-walk ^HEAD~3 HEAD"? Isn't it a nonsense? If it is "no walk", then why do you even list a negative one? As to cherry-pick, I wouldn't be surprised if it relies on the current internal working of pushing commits in the date order to the queue regardless of how they were given from the command line. Indeed, it does exactly that, and then tries to compensate it---notice that builtin/revert.c:prepare_revs() gives "revs->reverse" to it. That also needs to be fixed. -- 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