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:
>
> > 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@xxxxxxxxx < $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@xxxxxxxxxx
OOO http://www.madism.org
Attachment:
pgpQaR1cdryci.pgp
Description: PGP signature
