From: Junio C Hamano <gitster@pobox.com>
Date: Sat, 29 May 2010 15:27:01 GMT
Subject: Re: [RFC/PATCH 3/4] revert: allow cherry-picking a range of commits
Message-ID: <7vmxvi4tkq.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20100529044044.569.7874.chriscool@tuxfamily.org>

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