Christian Couder <chriscool@xxxxxxxxxxxxx> 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.
> @@ -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?
--
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