Subject: [bug#66618] [PATCH] etc: gitconfig: Remove the default email address to avoid mistakes.

From: Maxim Cournoyer <[email-masked]>
Date: Mon, 23 Oct 2023 10:28:06 -0400

Hi Simon,

Simon Tournier <[email-masked]> writes:

> Hi Maxim,
>
> On Fri, 20 Oct 2023 at 11:44, Maxim Cournoyer <[email-masked]> wrote:
>
>>> Here, the default
>>>
>>>      [sendemail]
>>>             to = [email-masked]
>>>
>>> makes something implicit – which is not necessary bad – but it hides
>>> potential errors – which is not good.
>>
>> But that's true for any automation of git.
>
> I disagree.  The aim of automation is to hide burden without being
> error-prone.
>
>
>>                                             If we follow that logic we
>> can remove the other git configurations because they may be surprising,
>
> The point is about being able to catch and adjust accordingly.  Except
> this ’sendemail.to’ value, all the other values may be surprising but if
> one is surprised, then one is aware of the non-default Git configuration
> and thus one is able to adjust accordingly.

The same hold for send-email.to.  You may get surprised once, and then
you know it.  The 'git send-email' command will prompt before sending
the email with something like:

--8<---------------cut here---------------start------------->8---
$ git send-email -1
;;; note: source file /home/maxim/src/guix/etc/teams.scm
;;;       newer than compiled /home/maxim/.cache/guile/ccache/3.0-LE-8-4.6/home/maxim/src/guix/etc/teams.scm.go
/tmp/YXDTZOc_v8/0001-wip-lfs.patch
;;; note: source file /home/maxim/src/guix/etc/teams.scm
;;;       newer than compiled /home/maxim/.cache/guile/ccache/3.0-LE-8-4.6/home/maxim/src/guix/etc/teams.scm.go
(mbox) Adding cc: Maxim Cournoyer <[email-masked]> from line 'From: Maxim Cournoyer <[email-masked]>'

From: [...]
To: [email-masked]
Cc: [...]
Subject: [PATCH] wip lfs
Date: Mon, 23 Oct 2023 10:11:24 -0400
Message-ID: <88ec0c8[email-masked]>
X-Mailer: git-send-email 2.41.0
MIME-Version: 1.0
X-Debbugs-Cc: [...]
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

    The Cc list above has been expanded by additional
    addresses found in the patch commit message. By default
    send-email prompts before sending whenever this occurs.
    This behavior is controlled by the sendemail.confirm
    configuration setting.

    For additional information, run 'git send-email --help'.
    To retain the current behavior, but squelch this message,
    run 'git config --global sendemail.confirm auto'.

Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): 
--8<---------------cut here---------------end--------------->8---

The 'To: ' field is visible in this summary before confirming whether
the email should be sent.

[...]

> I disagree.  For example, I think ’sendemail.headerCmd’ is a good
> default.  Because it hides the burden and correct my potential mistake.
>
> Well, somehow there is “good” surprise and “bad” surprise.  For me,
> ’sendemail.to’ leads to “bad” surprise and ’sendemail.headerCmd’ leads
> to “good” surprise.
>
> For me, ’sendemail.headerCmd’ helps because it behaves in a way that
> most users will expect the system to behave.  That’s POLA.  However,
> ’sendemail.to’ does not appear to me POLA because it hides my potential
> mistake.

That's subjective unfortunately; at least two committers were originally
surprised by the then new 'sendemail.headerCmd' behavior.

>>                                           The small cost in surprise is
>> offset by removing manual work for myself and I'd expect/hope other
>> committers.
>
> Well, from my point of view, it is possible to use other means for
> removing some manual work.  For instance, it is possible to have an
> alias in etc/gitconfig, as “git send-patches”.  Or it is possible to use
> ’sendemail.aliasesFile’ for having a short key to pass.  Or else.
>
> You said:
>
>         OK!  I'll leave this opened for a bit longer to allow for others to tip
>         in, after which I'll do so.
>
> and now you have two opinions by two Guix committers :-) – not
> git-send-email experts though but having some habits for using it. ;-)
>
> That’s said, I do not have a strong opinion either.  I can live with the
> default value since I always explicitly uses ’--to=’. :-) And if this
> default value suits your productivity, it is totally fine with me.

It does!  I don't see how forcing everyone to explicitly type
--to=[email-masked] for sending simple patches or cover
letters helps our flow.  Mistakes will happen, but that's human, and we
can merge or close the issue on Debbugs when they occur, without loosing
any sleep :-)

-- 
Thanks,
Maxim