All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Tan <jonathantanmy@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jonathan Tan <jonathantanmy@google.com>,
	Max Bernstein via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org,
	Max Bernstein <donotemailthisaddress@bernsteinbear.com>,
	Max Bernstein <max@bernsteinbear.com>,
	Christian Couder <christian.couder@gmail.com>
Subject: Re: [PATCH] trailer: allow spaces in tokens
Date: Thu, 18 Aug 2022 10:52:16 -0700	[thread overview]
Message-ID: <20220818175216.3530525-1-jonathantanmy@google.com> (raw)
In-Reply-To: <xmqqo7whqyzs.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:
> Jonathan, do you remember if the "be stricter" was in a response to
> specific real world issues, or is this "we no longer allow whitespace"
> an unintended side effect of the change?

Rereading the relevant mailing list thread, I think it's a bit of both.
The sequence of events was as follows:
 - I made a patch set that changed sequencer.c (which, among other
   things, controls the behavior of "commit -s") to use
   interpret-trailers's functionality. This caused a change in the
   behavior of a "commit -s" unit test (the "I want to mention about
   Signed-off-by: here." one), because "commit -s" previously did not
   support spaces before the separator. [1]
 - You mentioned that perhaps we should tighten it back. [2]
 - I agreed and tightened it, but didn't change the documentation. [3]

[1] https://lore.kernel.org/git/a416ab9b-ff1f-9a71-3e58-60fd4f8a6b8e@google.com/
[2] https://lore.kernel.org/git/xmqqtwbroykt.fsf@gitster.mtv.corp.google.com/
[3] https://lore.kernel.org/git/cover.1478028700.git.jonathantanmy@google.com/

So the "real world issue" was a test in our test suite, and perhaps the
side effect was unintended in that we wanted to preserve the behavior of
"commit -s" but didn't think about other possible uses of
interpret-trailers.

> If the former, an equally valid "fix" to what Max reports here would
> be to add such a real world issue or two as new tests to demonostrate
> why allowing whitespaces was a mistake that hurts real-world workflow,
> and fix the documentation.
>
> I actually am suspecting it is the latter, only because we would have
> added a testcase to show why whitespaces in the trailer label is a
> bad idea in e4319562 if this was triggered by a real-world issue.

The "I want to mention about Signed-off-by: here." test might be a
sufficient real-world issue.

> I would say that it would be a disaster, if we took any random
> line with colon : in it in the middle of the commit message and
> mistook it as a trailer (like the line above), but since we do not
> allow paragraph breaks in the trailer block, as long as the message
> has a valid trailer block, it might not be a huge issue.  I dunno.

Yes, it would be fine if the paragraph was two or more lines long, but
not if it's a single line.

  reply	other threads:[~2022-08-18 17:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-18  7:06 [PATCH] trailer: allow spaces in tokens Max Bernstein via GitGitGadget
2022-08-18  7:54 ` [PATCH v2] " Max Bernstein via GitGitGadget
2022-08-18 16:54   ` Junio C Hamano
2022-08-18 17:56     ` Jonathan Tan
2022-08-18 19:03     ` Maxwell Bernstein
2022-08-18 20:46       ` Christian Couder
2022-08-18 21:31         ` Junio C Hamano
2022-08-19  4:33           ` Junio C Hamano
2022-08-19 10:29             ` Christian Couder
2022-08-22 13:58               ` Johannes Schindelin
2022-08-23 14:06               ` [PATCH] Documentation: clarify whitespace rules for trailers Christian Couder
2022-08-24 18:13                 ` Junio C Hamano
2022-08-25 11:59                   ` Christian Couder
2022-08-25 16:20                     ` Junio C Hamano
2022-08-30 10:50                     ` [PATCH v2] " Christian Couder
2022-08-30 17:20                       ` Junio C Hamano
2022-08-18 16:48 ` [PATCH] trailer: allow spaces in tokens Junio C Hamano
2022-08-18 17:52   ` Jonathan Tan [this message]
2022-08-18 17:58     ` Junio C Hamano

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=20220818175216.3530525-1-jonathantanmy@google.com \
    --to=jonathantanmy@google.com \
    --cc=christian.couder@gmail.com \
    --cc=donotemailthisaddress@bernsteinbear.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=max@bernsteinbear.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 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.