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

On Sun, Nov 02, 2008 at 06:02:21PM +0000, Jeff King wrote:

Well that defeats the purpose of fixing send-email to me. I really would like to see this fixed properly like it should. I mean it makes sense to me to use _three_ commands where one should be enough. Not to mention that introducing a new command is just completely against the spirit of *simplifying* the current UI ;)

Actually I see a few possibilities.

(1) The first one is to pass a --[no]-format-patch flag to
    git-send-email which says that it should understand arguments as
    format-patch arguments.  You add to that a sendemail.format-patch
    setting that would default to false for backward compatibility sake,
    that would allow the user to force --format-patch as a default.

    This would e.g. cleanly allow:  git send-email --format-patch -3 HEAD.

    I would understand if people dislike the setting: it basically
    modifies the behaviour of a git command a lot, which has been
    frowned upon in the past. Even though I would argue than using
    git-send-email in scripting is quite bad, for something that you can
    probably replace with:

    while read patchname; do mail some@where.org < $patchname; done < git format-patch "$@"

    But if people think it's too dangerous, replacing it with a short
    switch so that it's not too painful to use would fly for me,
    something like -F or whatever.

(2) Another way is to add a --pass-to-format-patch kind of option that
    would take its arguments and pass it to git-format-patch. Like in:
    git send-email --pass-to-format-patch "-3 HEAD". (Of course a short
    switch would help ;p).

(3) Use -- for mandatory separating <format-patch> arguments like this:

	git send-email [send-email options] -- -3 HEAD

    or if you want to send patches that would modify only a given path:

        git send-email [s-e options] -- origin/next.. -- git-gui

    that would run internally:

        git format-patch origin/next.. -- git-gui

I would say that I dislike (2) a LOT because it's a pain to use: needs a lot of quoting, and it gets worse if you want to pass things with spaces in it to format-patch.

(2) has the small drawback of not being 100% backward compatible: with the current use of perl Getoptions, -- is used to stop options processing, and people _may_ have used it to do `git s-e -- --my.patch` and such a use would break. However this is highly unlikely to cause issues in real life I think (unlike the problem of refs against filename clashes).

In (1) people may dislike the idea of a setting, I've not strong feelings about it, I won't mind if it gets rejected, a short switch will do just fine then.

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 ?