[PATCH 3 of 3] patchbomb: make --git-format-patch imply --plain

[Henning Schild]

On Sun, 20 Nov 2016 19:38:43 +0900
Yuya Nishihara <yuya at tcha.org> wrote:

> On Thu, 17 Nov 2016 21:47:58 +0100, Henning Schild wrote:
> > # HG changeset patch
> > # User Henning Schild <henning at hennsch.de>
> > # Date 1479415557 -3600
> > #      Thu Nov 17 21:45:57 2016 +0100
> > # Node ID de2b03a509491020f728f1955e39e2bfb9a77426
> > # Parent  a9be53e26cb1ac19d1c0156062e8ae23f8366d8b
> > patchbomb: make --git-format-patch imply --plain
> > 
> > Not using --plain would generate mails with the hg header in the
> > git commit message. Since --git-format-patch already caters for
> > git, might as well make sure users do not forget --plain.
> > 
> > diff --git a/hgext/patchbomb.py b/hgext/patchbomb.py
> > --- a/hgext/patchbomb.py
> > +++ b/hgext/patchbomb.py
> > @@ -418,7 +418,7 @@
> >  @command('email',
> >      [('g', 'git', None, _('use git extended diff format')),
> >      ('', 'git-format-patch', None, _('use git-format-patch email
> > format '
> > -       '(implies --git)')),
> > +       '(implies --git and --plain)')),
> >      ('', 'plain', None, _('omit hg patch header')),
> >      ('o', 'outgoing', None,
> >       _('send changes not found in the target repository')),
> > @@ -527,6 +527,7 @@
> >  
> >      if (opts.get('git_format_patch')):
> >          opts['git'] = True
> > +        opts['plain'] = True
> >  
> >      if not (opts.get('test') or mbox):
> >          # really sending
> > diff --git a/tests/test-patchbomb.t b/tests/test-patchbomb.t
> > --- a/tests/test-patchbomb.t
> > +++ b/tests/test-patchbomb.t
> > @@ -755,13 +755,6 @@
> >    To: foo
> >    Cc: bar
> >    
> > -  # HG changeset patch
> > -  # User test
> > -  # Date 3 0
> > -  #      Thu Jan 01 00:00:03 1970 +0000
> > -  # Node ID ff2c9fa2018b15fa74b33363bda9527323e2a99f
> > -  # Parent  97d72e5f12c7e84f85064aa72e5a297142c36ed9
> > -  c  
> 
> But after reading this, I feel templating will be much nicer.

I have played with templates to get "Signed-off-by"s into commit
messages. That works but you have to configure it somewhere. Meaning
that every fresh clone will require dreadful customization, or that
global configuration will impose on every cloned repo.
To me it seems like maintaining my own templates is harder than
maintaining an mq in a custom mercurial. Using them you are basically
programming out of the tree, in a strange and limited language. With a
lot of references of what you expect the hg code to be, but no merge
conflicts on updates, no testing etc. Thinking about it this way,
templating is a fine mechanism for under the hood, but should never
have been exposed to the configs.

Lets assume supporting the git-format-patch format was a wanted
feature, and let us further assume "hg email" already used templates. hg
or hg-git would than come with a template for it, but how would that get
selected?

Henning