From: Phillip Wood <phillip.wood123@gmail.com>
To: Kristoffer Haugsbakk <code@khaugsbakk.name>,
Phillip Wood <phillip.wood@dunelm.org.uk>,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] notes: remove trailing whitespace from editor template
Date: Tue, 27 May 2025 09:24:26 +0100 [thread overview]
Message-ID: <ab009472-d15d-4894-aa83-0ab8b0d2dfbd@gmail.com> (raw)
In-Reply-To: <10280d7d-af36-468d-82b8-e0e780c38ef1@app.fastmail.com>
Hi Kristoffer
On 26/05/2025 20:44, Kristoffer Haugsbakk wrote:
> On Mon, May 26, 2025, at 16:01, Phillip Wood wrote:
>>> diff --git a/builtin/notes.c b/builtin/notes.c
>>> index a3f433ca4c0..ca4782eca19 100644
>>> --- a/builtin/notes.c
>>> +++ b/builtin/notes.c
>>> @@ -180,6 +180,8 @@ static void write_commented_object(int fd, const struct object_id *object)
>>> if (strbuf_read(&buf, show.out, 0) < 0)
>>> die_errno(_("could not read 'show' output"));
>>> strbuf_add_commented_lines(&cbuf, buf.buf, buf.len, comment_line_str);
>>> + /* strip trailing whitespace introduced by blank lines */
>>> + strbuf_stripspace(&cbuf, NULL);
>>
>> It doesn't make any difference at the moment but I'd be happier if we
>> stripped the trailing space from the commit message before commenting it
>> out. That way we know we are only stripping space from the indented
>> lines produced by "git show". If in the future this function were to
>> start appending the commented log message to a buffer passed in by the
>> caller rather than a file passed by the caller we wont mess up the rest
>> of the buffer content.
>
> Do you mean doing the operation on the output buffer instead?:
>
> if (strbuf_read(&buf, show.out, 0) < 0)
> die_errno(_("could not read 'show' output"));
> /* strip trailing whitespace introduced by blank lines */
> strbuf_stripspace(&buf, NULL);
> strbuf_add_commented_lines(&cbuf, buf.buf, buf.len, comment_line_str);
> write_or_die(fd, cbuf.buf, cbuf.len);
>
> I think that’s cleaner. But I don’t see how it makes the code more
> future-proof.
Because it is now stripping buf and not cbuf. If in the future we decide
to build the message in a buffer rather than writing it piecemeal to
disk we would change signature of this function to take an strbuf
instead of a file descriptor and use the buffer provided by the caller
instead of cbuf. If we were to strip cbuf then a naive conversion would
end up stripping the buffer passed by caller, not just the output from
"git show". Various git notes subcommands have a --stripspace option and
calling strbuf_stripspace() on the caller provided buffer would break that.
>>> write_or_die(fd, cbuf.buf, cbuf.len);
>> > [...]> +test_expect_success 'git notes add has no trailing whitespace
>> in the editor template' '
>>> + test_commit --signoff 23rd &&
>>> + GIT_EDITOR="cat >actual" git notes add &&
>>> + test_grep ! " $" actual
>>
>> Should that be " \$"? What you've got seems to work with dash but I'm
>> not sure if it is POSIX compliant or not.
>
> `$` is the anchor metacharacter in this context (end of string)
> according to Posix.
Right but what does the shell do to that '$'? It is not escaped and
inside a double quoted string.
Best Wishes
Phillip
next prev parent reply other threads:[~2025-05-27 8:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-24 21:35 [PATCH] notes: remove trailing whitespace from editor template kristofferhaugsbakk
2025-05-25 20:46 ` Kristoffer Haugsbakk
2025-05-26 14:01 ` Phillip Wood
2025-05-26 19:44 ` Kristoffer Haugsbakk
2025-05-27 8:24 ` Phillip Wood [this message]
2025-05-27 16:11 ` Kristoffer Haugsbakk
2025-05-27 17:18 ` Junio C Hamano
2025-05-27 17:28 ` Eric Sunshine
2025-05-27 21:21 ` Kristoffer Haugsbakk
2025-05-27 22:22 ` Junio C Hamano
2025-06-02 13:52 ` Phillip Wood
2025-06-03 20:37 ` D. Ben Knoble
2025-06-03 20:46 ` Eric Sunshine
2025-06-09 21:10 ` Kristoffer Haugsbakk
2025-06-09 21:12 ` Kristoffer Haugsbakk
2025-06-10 21:11 ` D. Ben Knoble
2025-06-10 22:55 ` 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=ab009472-d15d-4894-aa83-0ab8b0d2dfbd@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=code@khaugsbakk.name \
--cc=git@vger.kernel.org \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=phillip.wood@dunelm.org.uk \
/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 NNTP newsgroup(s).