Skip to content

Commit 1de69c0

Browse files
pks-tgitster
authored andcommitted
pretty: fix adding linefeed when placeholder is not expanded
When a formatting directive has a `+` or ` ` after the `%`, then we add either a line feed or space if the placeholder expands to a non-empty string. In specific cases though this logic doesn't work as expected, and we try to add the character even in the case where the formatting directive is empty. One such pattern is `%w(1)%+d%+w(2)`. `%+d` expands to reference names pointing to a certain commit, like in `git log --decorate`. For a tagged commit this would for example expand to `\n (tag: v1.0.0)`, which has a leading newline due to the `+` modifier and a space added by `%d`. Now the second wrapping directive will cause us to rewrap the text to `\n(tag:\nv1.0.0)`, which is one byte shorter due to the missing leading space. The code that handles the `+` magic now notices that the length has changed and will thus try to insert a leading line feed at the original posititon. But as the string was shortened, the original position is past the buffer's boundary and thus we die with an error. Now there are two issues here: 1. We check whether the buffer length has changed, not whether it has been extended. This causes us to try and add the character past the string boundary. 2. The current logic does not make any sense whatsoever. When the string got expanded due to the rewrap, putting the separator into the original position is likely to put it somewhere into the middle of the rewrapped contents. It is debatable whether `%+w()` makes any sense in the first place. Strictly speaking, the placeholder never expands to a non-empty string, and consequentially we shouldn't ever accept this combination. We thus fix the bug by simply refusing `%+w()`. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent f6e0b9f commit 1de69c0

File tree

2 files changed

+21
-1
lines changed

2 files changed

+21
-1
lines changed

pretty.c

Lines changed: 13 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1597,9 +1597,21 @@ static size_t format_commit_item(struct strbuf *sb, /* in UTF-8 */
15971597
default:
15981598
break;
15991599
}
1600-
if (magic != NO_MAGIC)
1600+
if (magic != NO_MAGIC) {
16011601
placeholder++;
16021602

1603+
switch (placeholder[0]) {
1604+
case 'w':
1605+
/*
1606+
* `%+w()` cannot ever expand to a non-empty string,
1607+
* and it potentially changes the layout of preceding
1608+
* contents. We're thus not able to handle the magic in
1609+
* this combination and refuse the pattern.
1610+
*/
1611+
return 0;
1612+
};
1613+
}
1614+
16031615
orig_len = sb->len;
16041616
if (((struct format_commit_context *)context)->flush_type != no_flush)
16051617
consumed = format_and_pad_commit(sb, placeholder, context);

t/t4205-log-pretty-formats.sh

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -879,6 +879,14 @@ test_expect_success 'log --pretty with invalid padding format' '
879879
test_cmp expect actual
880880
'
881881

882+
test_expect_success 'log --pretty with magical wrapping directives' '
883+
commit_id=$(git commit-tree HEAD^{tree} -m "describe me") &&
884+
git tag describe-me $commit_id &&
885+
printf "\n(tag:\ndescribe-me)%%+w(2)" >expect &&
886+
git log -1 --pretty="format:%w(1)%+d%+w(2)" $commit_id >actual &&
887+
test_cmp expect actual
888+
'
889+
882890
test_expect_success EXPENSIVE,SIZE_T_IS_64BIT 'log --pretty with huge commit message' '
883891
# We only assert that this command does not crash. This needs to be
884892
# executed with the address sanitizer to demonstrate failure.

0 commit comments

Comments
 (0)