y...@google.com writes:
[Administrivia: I somehow doubt y...@google.com would reach you, and
futzed with the To: line above]
> From: Martin von Zweigbergk <martin.von.zweigbe...@gmail.com>
>
> 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 <gits...@pobox.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
