From: Hans-Peter Nilsson <hp@bitrange.com>
To: Martin Sebor <msebor@gmail.com>
Cc: Jonathan Wakely <jwakely@redhat.com>,
Jakub Jelinek <jakub@redhat.com>,
gcc@gcc.gnu.org
Subject: Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog
Date: Wed, 16 Jun 2021 13:44:50 -0400 (EDT) [thread overview]
Message-ID: <alpine.BSF.2.20.16.2106161328500.36658@arjuna.pair.com> (raw)
In-Reply-To: <cf56da64-451b-d33f-278d-cbbfee28aaa7@gmail.com>
On Tue, 15 Jun 2021, Martin Sebor wrote:
> On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
> > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
> >
> > > On 6/11/21 11:32 AM, Jonathan Wakely wrote:
> > > > On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
> > > > > My objection is to making our policies and tools more restrictive
> > > > > than they need to be. We shouldn't expect everyone to study whole
> > > > > manuals just to figure out how to successfully commit a change (or
> > > > > learn how to format it just the right way). It should be easy.
> > > >
> > > > I agree, to some extent. But consistency is also good. The conventions
> > > > for GNU ChangeLog formatting exist for a reason, and so do the
> > > > conventions for good Git commit messages.
> > > >
> > > > > Setting this discussion aside for a moment and using a different
> > > > > example, the commit hook rejects commit messages that don't start
> > > > > ChangeLog entries with tabs. It also rejects commit messages that
> > > > > don't list all the same test files as those changed by the commit
> > > > > (and probably some others as well). That's in my view unnecessary
> > > > > when the hook could just replace the leading spaces with tabs and
> > > >
> > > > You cannot "fix things up" in a server-side receive hook, because
> > > > changing the commit message would alter the commit hash, which would
> > > > require the committer to do a rebase to proceed. That breaks the
> > > > expected behaviour and workflow of a git repo.
> > > >
> > > > You can use the scripts on the client side to verify your commit
> > > > message before pushing, so you don't have to be surprised when the
> > > > server rejects it.
> > >
> > > That sounds like a killer argument. Do we have shared client-side
> > > scripts that could fix things up for us, or are we each on our own
> > > to write them?
> >
> > > > > automatically mention all the tests.
> > > > >
> > > > > I see this proposal as heading in the same direction. Rather than
> > > > > making the script fix things up if we get them wrong it would reject
> > > > > the commit, requiring the user to massage the ChangeLog by hand into
> > > > > an unnecessarily rigid format.
> > I hope I got your view wrong. If not: the "scripts fixing
> > things up for us" direction is flawed (compared to the "scripts
> > rejecting bad formats"), unless offered as a non-default option;
> > please don't proceed.
> >
> > Why? For one, there'll always be bugs in the scripting.
> > Mitigate those situations: while wrongly rejecting a commit is
> > bad, wrongly "fixing things up" is worse, as a general rule.
> > Better avoid that. (There's probably a popular "pattern name"
> > for what I try to describe.)
>
> The word that comes to mind is Technophobia. Is it wise to trust
> compilers to transform programs from their source form into
> executables? What if there are bugs in either? What about the OS?
> The whole computer, or the Internet? Our cars? Fortunately, there's
> more to gain than to lose by trusting automation. If there weren't
> human progress would be stuck sometime in the 1700's.
>
> But we're not talking about anything anywhere that sophisticated
> here: a sed script to copy and paste a piece of text in
> the description of a change from one place to another. It's been
> done a few times before with more important data than ChangeLogs.
Your hyperbole would be funnier if it wasn't too much over the
top. Criticizing the suggested approach for suffering from a
technical fallacy ("outsmarting the user") isn't technophobia.
Keep it in the helper scripts, don't put it in a commit hook.
brgds, H-P
next prev parent reply other threads:[~2021-06-16 17:44 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4c1114a7-2377-99e4-d451-1a086857e991@linux.ibm.com>
2021-06-10 5:22 ` Xionghu Luo
2021-06-10 6:17 ` Martin Liška
2021-06-10 6:25 ` Xionghu Luo
2021-06-10 8:07 ` Martin Liška
2021-06-10 6:35 ` Tobias Burnus
2021-06-10 8:07 ` Martin Liška
2021-06-10 9:44 ` Jonathan Wakely
2021-06-10 10:01 ` Jonathan Wakely
2021-06-10 10:08 ` Jakub Jelinek
2021-06-10 10:40 ` Jonathan Wakely
2021-06-10 14:55 ` Martin Sebor
2021-06-10 15:54 ` Tobias Burnus
2021-06-10 16:05 ` Jonathan Wakely
2021-06-10 15:56 ` Jonathan Wakely
2021-06-10 17:06 ` Martin Sebor
2021-06-10 17:20 ` Martin Sebor
2021-06-10 17:30 ` Jakub Jelinek
2021-06-10 18:55 ` Martin Sebor
2021-06-10 19:09 ` Jakub Jelinek
2021-06-10 21:16 ` Martin Sebor
2021-06-10 21:28 ` Jakub Jelinek
2021-06-10 21:56 ` Martin Sebor
2021-06-11 9:13 ` Jonathan Wakely
2021-06-11 17:02 ` Martin Sebor
2021-06-11 17:05 ` Jakub Jelinek
2021-06-11 17:32 ` Jonathan Wakely
2021-06-11 18:01 ` Martin Sebor
2021-06-11 18:14 ` Jonathan Wakely
2021-06-16 0:56 ` Hans-Peter Nilsson
2021-06-16 2:03 ` Martin Sebor
2021-06-16 3:42 ` Jason Merrill
2021-06-16 14:31 ` Martin Sebor
2021-06-16 20:49 ` Jason Merrill
2021-06-16 21:45 ` Martin Sebor
2021-06-16 23:45 ` Jason Merrill
2021-06-17 0:17 ` Martin Sebor
2021-06-17 0:40 ` Jason Merrill
2021-06-17 1:01 ` Martin Sebor
2021-06-17 1:46 ` Jason Merrill
2021-06-17 10:18 ` Jonathan Wakely
2021-06-17 14:55 ` Martin Sebor
2021-06-17 15:11 ` Michael Matz
2021-06-17 15:33 ` Martin Sebor
2021-06-17 16:31 ` Jakub Jelinek
2021-06-17 16:32 ` Jonathan Wakely
2021-06-17 18:00 ` Martin Sebor
2021-06-17 10:08 ` Richard Earnshaw
2021-06-17 17:12 ` Joseph Myers
2021-06-17 17:21 ` Jason Merrill
2021-06-17 17:21 ` Jakub Jelinek
2021-06-18 9:32 ` Richard Earnshaw
2021-06-18 11:05 ` [Patch] contrib/mklog.py: Improve PR handling (was: git gcc-commit-mklog doesn't extract PR number to ChangeLog) Tobias Burnus
2021-06-18 11:10 ` Jonathan Wakely
2021-06-18 11:24 ` Jakub Jelinek
2021-06-18 11:25 ` Tobias Burnus
2021-06-18 11:40 ` Jonathan Wakely
2021-06-21 7:28 ` Martin Liška
2021-06-18 16:40 ` [Patch] contrib/mklog.py: Improve PR handling Martin Sebor
2021-06-18 14:41 ` [Patch] contrib/mklog.py: Improve PR handling (was: git gcc-commit-mklog doesn't extract PR number to ChangeLog) Jason Merrill
2021-06-18 16:47 ` [Patch] contrib/mklog.py: Improve PR handling Martin Sebor
2021-06-18 16:59 ` Iain Sandoe
2021-06-21 6:42 ` [Patch] contrib/mklog.py: Improve PR handling (was: git gcc-commit-mklog doesn't extract PR number to ChangeLog) Tobias Burnus
2021-06-21 7:26 ` Martin Liška
2021-06-21 8:02 ` Iain Sandoe
2021-06-21 7:54 ` [Patch, v2] contrib/mklog.py: Improve PR handling (was: " Tobias Burnus
2021-06-21 8:09 ` Martin Liška
2021-06-21 8:37 ` Tobias Burnus
2021-06-21 12:53 ` Martin Liška
2021-06-21 13:26 ` Tobias Burnus
2021-06-22 7:30 ` [RFC][PATCH] contrib: add git-commit-mklog wrapper Martin Liška
2021-06-22 8:23 ` Tobias Burnus
2021-06-22 8:31 ` Martin Liška
2021-06-22 18:40 ` Jason Merrill
2021-06-23 7:40 ` Martin Liška
2021-06-16 13:46 ` git gcc-commit-mklog doesn't extract PR number to ChangeLog Jonathan Wakely
2021-06-16 17:44 ` Hans-Peter Nilsson [this message]
2021-06-11 9:08 ` Jonathan Wakely
2021-06-11 9:35 ` Jonathan Wakely
2021-06-11 15:43 ` Joseph Myers
2021-06-11 17:02 ` Jonathan Wakely
2021-06-10 11:51 ` [Patch] contrig/gcc-changelog: Check that PR in subject in in changelog (was:: git gcc-commit-mklog doesn't extract PR number to ChangeLog) Tobias Burnus
2021-06-10 11:54 ` [Patch] contrig/gcc-changelog: Check that PR in subject in in changelog Florian Weimer
2021-06-10 12:45 ` Jonathan Wakely
2021-06-10 9:41 ` git gcc-commit-mklog doesn't extract PR number to ChangeLog Jonathan Wakely
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=alpine.BSF.2.20.16.2106161328500.36658@arjuna.pair.com \
--to=hp@bitrange.com \
--cc=gcc@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jwakely@redhat.com \
--cc=msebor@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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).