[PATCH] send-email: make annotate configurable

[PATCH] send-email: make annotate configurable

[Felipe Contreras]

Some people always do --annotate, lets not force them to always type
that.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Documentation/config.txt         |    1 +
 Documentation/git-send-email.txt |    5 +++--
 git-send-email.perl              |    3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index c081657..90c9e1b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1828,6 +1828,7 @@ sendemail.<identity>.*::
 
 sendemail.aliasesfile::
 sendemail.aliasfiletype::
+sendemail.annotate::
 sendemail.bcc::
 sendemail.cc::
 sendemail.cccmd::
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 3241170..2106fea 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -45,8 +45,9 @@ Composing
 ~~~~~~~~~
 
 --annotate::
-	Review and edit each patch you're about to send. See the
-	CONFIGURATION section for 'sendemail.multiedit'.
+	Review and edit each patch you're about to send. Default is the value
+	of 'sendemail.annotate'. See the CONFIGURATION section for
+	'sendemail.multiedit'.
 
 --bcc=<address>::
 	Specify a "Bcc:" value for each email. Default is the value of
diff --git a/git-send-email.perl b/git-send-email.perl
index ef30c55..6ef2d34 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -210,7 +210,8 @@ my %config_bool_settings = (
     "signedoffbycc" => [\$signed_off_by_cc, undef],
     "signedoffcc" => [\$signed_off_by_cc, undef],      # Deprecated
     "validate" => [\$validate, 1],
-    "multiedit" => [\$multiedit, undef]
+    "multiedit" => [\$multiedit, undef],
+    "annotate" => [\$annotate, undef]
 );
 
 my %config_settings = (
-- 
1.7.10

Re: [PATCH] send-email: make annotate configurable

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Some people always do --annotate, lets not force them to always type
> that.

Thanks.

As long as there is --no-annotate to cancel a configured value for
one-shot invocation (I didn't check, but it should be added if there isn't
already one), I think this change makes sense (I admit that I do not use
the --annotate option myself, though).

Are there any other bool-ish command line option that deserves to have
corresponding configuration variable?  Is this the only one that is
missing the configuration counterpart?

Re: [PATCH] send-email: make annotate configurable

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Some people always do --annotate, lets not force them to always type
>> that.
>
> Thanks.
>
> As long as there is --no-annotate to cancel a configured value for
> one-shot invocation (I didn't check, but it should be added if there isn't
> already one), I think this change makes sense (I admit that I do not use
> the --annotate option myself, though).

I almost always use --annotate, so this option definitely makes sense
for me (I usually call send-email through an alias that adds --annotate
anyway).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH] send-email: make annotate configurable

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> As long as there is --no-annotate to cancel a configured value for
>> one-shot invocation (I didn't check, but it should be added if there isn't
>> already one), I think this change makes sense (I admit that I do not use
>> the --annotate option myself, though).
>
> I almost always use --annotate, so this option definitely makes sense
> for me (I usually call send-email through an alias that adds --annotate
> anyway).

I do not doubt the usefulness of it, but if there is no --no-annotate, it
would make the new variable unusable for those who would never run it
without --annotate option; while you said "almost always", you didn't give
us any useful information, so I had to check ;-)  It turns out that

    $ git send-email --no-annotate </dev/null

errors out with "unrecognized argument: --no-annotate", which first needs
to be addressed before the configuration variable can become useful.

Re: [PATCH] send-email: make annotate configurable

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> I do not doubt the usefulness of it, but if there is no --no-annotate, it
> would make the new variable unusable for those who would never run it
> without --annotate option

Sorry; I meant to say "for those who mostly but not always run it with
the --annotate option".

Re: [PATCH] send-email: make annotate configurable

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> I do not doubt the usefulness of it, but if there is no --no-annotate, it
>> would make the new variable unusable for those who would never run it
>> without --annotate option
>
> Sorry; I meant to say "for those who mostly but not always run it with
> the --annotate option".

Actually, I guess you also meant "and who sometimes use older versions
of Git", since the --no-annotate is there for people who always use the
new version.

I don't think we can do anything for it. Any patch that introduces a new
command-line option has the same issue. The only solution is on the user
side: use only features that work for all versions of Git you use. In
this case, it means "wait for all your machines to upgrade Git before
setting sendemail.annotate".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH] send-email: make annotate configurable

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> I do not doubt the usefulness of it, but if there is no --no-annotate, it
>>> would make the new variable unusable for those who would never run it
>>> without --annotate option
>>
>> Sorry; I meant to say "for those who mostly but not always run it with
>> the --annotate option".
>
> Actually, I guess you also meant "and who sometimes use older versions
> of Git", since the --no-annotate is there for people who always use the
> new version.

Not really.  I didn't even have that in mind, and I agree with below.

> I don't think we can do anything for it. Any patch that introduces a new
> command-line option has the same issue. The only solution is on the user
> side: use only features that work for all versions of Git you use. In
> this case, it means "wait for all your machines to upgrade Git before
> setting sendemail.annotate".

And for that to work well, it is most sensible for the version that
introduces the configuration variable to make sure that the --no-annotate
command line override also is there, as the override becomes even more
necessary because of the configuration variable.