Re: [take 2] git send-email updates

[Pierre Habouzit <madcoder@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]

On Tue, Nov 11, 2008 at 08:30:51PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
> 
> > The last patch is dropped for now (the automatic --compose stuff)
> > because I'm not sure which option to add, and that I don't care enough
> > about it to spend more time on it.
> >
> > I think I've incorporated most of the stuff people asked about in this
> > series.
> >
> >  [PATCH 1/4] git send-email: make the message file name more specific.
> >  [PATCH 2/4] git send-email: interpret unknown files as revision lists
> >  [PATCH 3/4] git send-email: add --annotate option
> >  [PATCH 4/4] git send-email: ask less questions when --compose is used.
> 
> Thanks.
> 
> It is somewhat unfortunate that an explicit --no-format-patch works
> exactly the same way as not giving the option at all.

Unless I'm mistaken in my code, and I may really be, it doesn't.
--format-patch says that in case of conflicts, the "revision" kind of
argument wins, --no-format-patch says that the "file" one wins, without
any it dies with an error. It's really a tristate, but maybe I missed
your point ?

> I would have expected that it would guess and warn if you did not give
> either, and it would not even guess (i.e. file is mbox, dir is
> maildir) and error out if there is a leftover option in @rev_list_opts
> if the user explicitly asked the command not act as a frontend to
> format patch.

Oh you mean that if one use --no-format-patch you don't wan't _any_
option to be passed to format-patch ? Hmmm I don't know, both what I did
and that are sane, I don't really know what to chose. But if we're going
to go down this road, _your_ --no-format-patch and --format-patch don't
quite do the opposite, as --format-patch still allows files to be passed
to it.

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.

But in the end, I believe this _may_ quite be slightly over-engineered in
the end ;) I would gladly implement the combination people like most, as
soon as I can pass format-patch option a way or the other, I'm happy :)

> I will queue the series in 'pu' because I suspect you would like a chance
> to amend out a "print foo" from the second commit ;-)

*ooops*

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]