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:

On Sun, Nov 02, 2008 at 10:39:07AM +0100, Pierre Habouzit wrote:

quoted

Well it still messes the file/reference name conflict with no way to
prevent it because of the backward compatibility, and even if unlikely
it's still possible.

Hmm. As Junio mentioned, this is really an easier way of doing:

  git format-patch -o tmp "$@"
  $EDITOR tmp/*
  git send-email tmp

So I guess a wrapper program would suffice, that just called send-email.
But of course then you would have to think of a new name, and explain
the confusion between it and send-email.

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 ?

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org