Pierre Habouzit <madcoder@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx -M --suppress-cc=all origin
and notice "--to git@xxxxxxxxxxxxxxx" 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@xxxxxxxxxxxxxxx --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?
--
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
