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

[Junio C Hamano <gitster@pobox.com>]

Pierre Habouzit <madcoder@debian.org> writes:

> 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?