Re: [RFC/PATCH 3/4] revert: allow cherry-picking a range of commits

On Saturday 29 May 2010 17:27:01 Junio C Hamano wrote:

Christian Couder [off-list ref] writes:

quoted

This makes it possible to pass a range of commits like A..B
to "git cherry-pick" and to "git revert" to process many
commits instead of just one.

@@ -545,6 +542,40 @@ static int revert_or_cherry_pick(int argc, const

char **argv) if (read_cache() < 0)
 		die("git %s: failed to read the index", me);

+	dotdot = strstr(commit_name, "..");
+	if (dotdot) {
+		struct rev_info revs;
+		const char *argv[4];
+		int argc = 0;
+
+		argv[argc++] = NULL;
+		if (action != REVERT)
+			argv[argc++] = "--reverse";
+		argv[argc++] = commit_name;
+		argv[argc++] = NULL;
+
+		init_revisions(&revs, NULL);

The goal of the series is a worthy one, but I would imagine people would
want to run these while on "maint":

    git cherry-pick master~2..master
    git cherry-pick master^ master

or even

    git cherry-pick -2 master

How about enumerating the commits with an equivalent of

    git rev-list --no-walk "$@"

as an alternative implementation?

I agree that it would be nice, but I am not sure it would allow using "-2 
master" as arguments because "--no-walk" seems to take over "-2": 

$ git rev-list --no-walk -2 master
81fa024cd8e336ba257f13fe7724b95baacfa3ad
$

The current behaviour would fall out just as a natural special case
because

    git rev-list --no-walk $commit == $commit

Hmm?

Yes, I will provide an updated patch series using the equivalent of '--no-walk 
"$@"' but arguments like "-2 master" will not work.

Thanks,
Christian.