Re: [take 2] git send-email updates

From: Pierre Habouzit <madcoder@debian.org>
Date: Nov 11, 2008, 22:13 UTC
Message-ID: <20081111221351.GE10073@artemis.corp>
In-Reply-To: <7v4p2e0zus.fsf@gitster.siamese.dyndns.org>

On Tue, Nov 11, 2008 at 08:30:51PM +0000, Junio C Hamano wrote:

Show 18 quoted lines

> 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 ?

Show 5 quoted lines

> 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