all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Simon Tournier <zimon.toutoune@gmail.com>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: 66618@debbugs.gnu.org, "Clément Lassieur" <clement@lassieur.org>
Subject: [bug#66618] [PATCH] etc: gitconfig: Remove the default email address to avoid mistakes.
Date: Mon, 23 Oct 2023 11:49:23 +0200	[thread overview]
Message-ID: <87ttqhllcs.fsf@gmail.com> (raw)
In-Reply-To: <87y1fxguxk.fsf@gmail.com>

Hi Maxim,

On Fri, 20 Oct 2023 at 11:44, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

>> Here, the default
>>
>>      [sendemail]
>>             to = guix-patches@gnu.org
>>
>> 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 issue with ’sendemail.to’ is that there is no surprise popping; for
being surprised, I need to be aware and here it does it in my back.

> and the send-email hook that notifies people, because that can again be
> surprising.

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.

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

Cheers,
simon






  parent reply	other threads:[~2023-10-23 12:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18 22:23 [bug#66618] [PATCH] etc: gitconfig: Remove the default email address to avoid mistakes Clément Lassieur
2023-10-19  1:34 ` Maxim Cournoyer
2023-10-19  9:46   ` Clément Lassieur
2023-10-19  1:36 ` Maxim Cournoyer
2023-10-19  9:37   ` Clément Lassieur
2023-10-20  1:54     ` Maxim Cournoyer
2023-10-20  8:42       ` Clément Lassieur
2023-10-20 14:06       ` Simon Tournier
2023-10-20 15:44         ` Maxim Cournoyer
2023-10-22 20:55           ` Clément Lassieur
2023-10-23  0:30             ` Maxim Cournoyer
2023-10-23  9:57               ` Simon Tournier
2023-10-23 14:17                 ` Maxim Cournoyer
2023-10-25 20:11               ` Clément Lassieur
2023-10-26  8:31                 ` Simon Tournier
2023-10-26 10:38                   ` bug#66618: " Clément Lassieur
2023-10-23  9:49           ` Simon Tournier [this message]
2023-10-23 14:28             ` [bug#66618] " Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ttqhllcs.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=66618@debbugs.gnu.org \
    --cc=clement@lassieur.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.