From: "Martin Ågren" <martin.agren@gmail.com>
To: git@vger.kernel.org
Subject: [PATCH 5/8] pretty: after padding, reset padding info
Date: Wed, 19 Mar 2025 08:23:38 +0100 [thread overview]
Message-ID: <e34ae37982e76179aee780c70b48aaaf959a307b.1742367347.git.martin.agren@gmail.com> (raw)
In-Reply-To: <cover.1742367347.git.martin.agren@gmail.com>
After handling a padding directive ("%<" or "%>"), we leave the `struct
padding_args` in a halfway state. We modify it a bit as we apply the
padding/truncation so that by the time we're done, it can't be in quite
as many states as when we started. Still, we don't fully restore it to
its default, no-action state.
"%<" and "%>" should only affect the next placeholder, but leaving a bit
of state around doesn't make it obvious that we don't spill any of it
into our handling of later placeholders. The previous commit closed off
a way of populating only half the `struct padding_args`, thereby fixing
a bug that *also* relied on then having the other half contain this kind
of lingering data.
After that fix, I haven't figured out a way to provoke a bug using just
this here half of the issue. Still, after handling padding, let's drop
all remnants of the previous "%<" or "%>".
Unlike the bug fixed in the previous commit, this could have some
realistic chance of regressing something for someone if they've actually
been using such state leftovers (knowingly or not). Still, it seems
worthwhile to try to tighten this.
This change to pretty.c would have been sufficient to make the test
added in the previous commit pass. Belt and suspenders.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
pretty.c | 2 ++
t/t4205-log-pretty-formats.sh | 9 +++++++++
2 files changed, 11 insertions(+)
diff --git a/pretty.c b/pretty.c
index a4fa052f8b..f53e77ed86 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1893,6 +1893,8 @@ static size_t format_and_pad_commit(struct strbuf *sb, /* in UTF-8 */
}
strbuf_release(&local_sb);
c->pad.flush_type = no_flush;
+ c->pad.truncate = trunc_none;
+ c->pad.padding = 0;
return total_consumed;
}
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 26987ecd77..d34a7cec09 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -1124,6 +1124,15 @@ test_expect_success 'log --pretty with space stealing' '
test_cmp expect actual
'
+test_expect_success 'only the next placeholder gets truncated' '
+ {
+ git log -1 --pretty="format:%<(4,trunc)%H" &&
+ printf "$(git rev-parse HEAD)"
+ } >expect &&
+ git log -1 --pretty="format:%<(4,trunc)%H%H" >actual &&
+ test_cmp expect actual
+'
+
test_expect_success 'log --pretty with invalid padding format' '
printf "%s%%<(20" "$(git rev-parse HEAD)" >expect &&
git log -1 --pretty="format:%H%<(20" >actual &&
--
2.49.0.472.ge94155a9ec
next prev parent reply other threads:[~2025-03-19 7:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 7:23 [PATCH 0/8] pretty: minor bugfixing, some refactorings Martin Ågren
2025-03-19 7:23 ` [PATCH 1/8] pretty: tighten function signature to not take `void *` Martin Ågren
2025-03-20 9:18 ` Patrick Steinhardt
2025-03-19 7:23 ` [PATCH 2/8] pretty: simplify if-else to reduce code duplication Martin Ågren
2025-03-20 9:17 ` Patrick Steinhardt
2025-03-20 16:10 ` Martin Ågren
2025-03-24 3:50 ` Jeff King
2025-03-19 7:23 ` [PATCH 3/8] pretty: collect padding-related fields in separate struct Martin Ågren
2025-03-19 7:23 ` [PATCH 4/8] pretty: fix parsing of half-valid "%<" and "%>" placeholders Martin Ågren
2025-03-20 9:18 ` Patrick Steinhardt
2025-03-20 16:11 ` Martin Ågren
2025-03-24 10:10 ` Patrick Steinhardt
2025-03-19 7:23 ` Martin Ågren [this message]
2025-03-20 9:18 ` [PATCH 5/8] pretty: after padding, reset padding info Patrick Steinhardt
2025-03-20 16:11 ` Martin Ågren
2025-03-19 7:23 ` [PATCH 6/8] pretty: refactor parsing of line-wrapping "%w" placeholder Martin Ågren
2025-03-20 9:18 ` Patrick Steinhardt
2025-03-20 16:11 ` Martin Ågren
2025-03-19 7:23 ` [PATCH 7/8] pretty: refactor parsing of magic Martin Ågren
2025-03-20 9:18 ` Patrick Steinhardt
2025-03-20 16:12 ` Martin Ågren
2025-03-19 7:23 ` [PATCH 8/8] pretty: refactor parsing of decoration options Martin Ågren
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=e34ae37982e76179aee780c70b48aaaf959a307b.1742367347.git.martin.agren@gmail.com \
--to=martin.agren@gmail.com \
--cc=git@vger.kernel.org \
/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).