Re: [PATCH] git send-email: allow any rev-list option as an argument.

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 4, 2008, 01:04 UTC
Message-ID: <7vej1sti78.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20081103091513.GC13930@artemis.corp>

Pierre Habouzit <madcoder@debian.org> writes:

Show 6 quoted lines

> As a summary, I'd say that I like both (1) and (3) because those are
> handy, short, and either completely or mostly backward compatible. My
> way would be to go down (1) and add a alias.s-e = !git send-email -F in
> my .gitconfig.
>
> What do you think ?

I wonder if we can do this even without an explicit -F.

What command line arguments does send-email take, and what options would we want to give the underlying format-patch? Can't you sift them without ambiguity?

The current syntax is:

    git send-email <flags>... <file|dir>...

I am wondering if we can just extend it to:

    git send-email <flags>... <<file|dir>...|rev>

E.g. we should be able to parse this out:

    git send-email --to git@vger.kernel.org -M --suppress-cc=all origin

and notice "--to git@vger.kernel.org" and "--suppress-cc" are for send-email, guess "-M" (or anything that is outside the current send-email's vocabulary) is meant for format-patch, and if there is no file or directory called "origin" then decide that the user wants to run format-patch, and act as a front-end as if the user did:

	git format-patch -o tmp.$$ -M origin &&
        ... perhaps do your --annotate and --compose here by launching
        ... the editor...
        git send-email --to git@vger.kernel.org --suppress-cc=all tmp.$$ &&
	rm -fr tmp.$$

If you happen to have a file or a directory called origin, it would be safer for users if the command errored out asking for disambiguation. The user can either say "./origin" or "origin^0" to disambiguate between them.

Hmm?