[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [take 2] git send-email updates
From:       Pierre Habouzit <madcoder () debian ! org>
Date:       2008-11-15 22:05:10
Message-ID: 20081115220510.GA11895 () artemis ! corp
[Download RAW message or body]

On Wed, Nov 12, 2008 at 12:14:20AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
> 
> > Oh you mean that if one use --no-format-patch you don't wan't _any_
> > option to be passed to format-patch?
> 
> The option name --no-format-patch sounded like "I do not want you to act
> as a frontend, ever", i.e. if you type master..next by mistake on the
> command line, the command would barf when the option is given.  Not even
> "pass to format-patch", but "do not run format-patch to begin with".
> 
> It is not a big deal especially for interactive use (and that is why I
> said "somewhat" unfortunate).
> 
> > If we're really doing this, then maybe we want a 5-state kind of option:
> >   1 disallow any file name ;
> >   2 if conflict, chose the revision ;
> >   3 barf if any conflict arises (default) ;
> >   4 if conflict chose the file ;
> >   5 disallow any kind of revision argument.
> >
> > My proposal implements 2 as --format-patch, 3 as default, and 4 as
> > --no-format-patch. You propose basically (5) for --no-format-patch
> > instead, well I say this makes sense, but it's somehow "sad" not to have
> > (1) too in that case.
> 
> Actually, "send-email --format-patch master..fixes Documentation/" may be
> a useful command to send out only documentation fixes.  For such a usage,
> Documentation/ should not be taken as a maildir.  If we would want to
> support such usage (and I'd say why not), a token can fall into one (or
> two) of three categories:

You can do that doing:

git send-email --format-patch master..fixes -- Documentation/

I've kept the `--` usual meaning, and it's sent to git-format-patch
verbatim and it'll work, so it's not required to change the meaning of
the options for that.

[sorry for the late reply, I've been somehow busy lately]

The sole conflict we have is when there is a path/rev conflict *before*
the `--` because of the legacy of git-send-email. I believe that
--format-patch should still allow to send patches passed on the command
line, this way.

> As to options, how about doing this:
> 
>     --no-format-patch means never ever run format-patch, behave exactly as
>     before;
> 
>     --format-patch means what you have in your patch.  guess and favor 
>     format-patch parameter when ambiguous;
> 
>     without either option, guess and favor mbox/maildir but still run
>     format-patch if remaining parameters and options need to
>     (e.g. "send-email my-cover-letter origin/master..master" will find
>     my-cover-letter which is not tracked and take it as mbox, and grab
>     patches from commits between origin/master..master, and send all of
>     them).

That's sane and I like it.
-- 
 ·O ·  Pierre Habouzit
 · ·O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[Attachment #3 (application/pgp-signature)]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[prev in list] [next in list] [prev in thread] [next in thread]