y@xxxxxxxxxx writes: [Administrivia: I somehow doubt y@xxxxxxxxxx would reach you, and futzed with the To: line above] > From: Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> > > This series adds supports for 'git log --no-walk=unsorted', which > should be useful for the re-roll of my mz/rebase-range series. It also > addresses the bug in cherry-pick/revert, which makes it sort revisions > by date. > > On Fri, Aug 10, 2012 at 11:28 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Range limited revision walking, e.g. "git cherry-pick A..B D~4..D", >> fundamentally implies sorting and you cannot assume B would appear >> before D only because B comes before D on the command line (B may >> even be inside D~4..D range in which case it would not even appear >> in the final output). > > Sorry, I probably wasn't clear; I mentioned "revision walking", but I > only meant the no-walk case. I hope the patches make sense. I actually think --no-walk, especially when given any negative revision, that sorts is fundamentally a flawed concept (it led to the inconsistency that made "git show A..B C" vs "git show C A..B" behave differently, which we had to fix recently). Would anything break if we take your patch, but without two possibilities to revs->no_walk option (i.e. we never sort under no_walk)? That is, the core of your change would become something like this: revision.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/revision.c b/revision.c index 9e8f47a..589d17f 100644 --- a/revision.c +++ b/revision.c @@ -2116,12 +2116,12 @@ int prepare_revision_walk(struct rev_info *revs) } e++; } - commit_list_sort_by_date(&revs->commits); if (!revs->leak_pending) free(list); if (revs->no_walk) return 0; + commit_list_sort_by_date(&revs->commits); if (revs->limited) if (limit_list(revs) < 0) return -1; -- 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