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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:48:52

Christian Couder [off-list ref] writes:
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.
quoted hunk
@@ -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?

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

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

Hmm?

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

From: Christian Couder <hidden>
Date: 2016-06-15 22:48:52

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.


 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help