log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 20:59:58 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='test log with i18n features'
|
2024-05-27 11:46:44 +00:00
|
|
|
|
|
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2019-06-27 23:39:04 +00:00
|
|
|
. ./lib-gettext.sh
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 20:59:58 +00:00
|
|
|
|
|
|
|
|
# two forms of é
|
|
|
|
|
utf8_e=$(printf '\303\251')
|
|
|
|
|
latin1_e=$(printf '\351')
|
|
|
|
|
|
2019-06-27 23:39:04 +00:00
|
|
|
# invalid UTF-8
|
|
|
|
|
invalid_e=$(printf '\303\50)') # ")" at end to close opening "("
|
|
|
|
|
|
2020-05-18 18:44:16 +00:00
|
|
|
have_reg_illseq=
|
|
|
|
|
if test_have_prereq GETTEXT_LOCALE &&
|
|
|
|
|
! LC_ALL=$is_IS_locale test-tool regex --silent $latin1_e
|
|
|
|
|
then
|
|
|
|
|
have_reg_illseq=1
|
|
|
|
|
fi
|
|
|
|
|
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 20:59:58 +00:00
|
|
|
test_expect_success 'create commits in different encodings' '
|
|
|
|
|
test_tick &&
|
|
|
|
|
cat >msg <<-EOF &&
|
|
|
|
|
utf8
|
|
|
|
|
|
|
|
|
|
t${utf8_e}st
|
|
|
|
|
EOF
|
|
|
|
|
git add msg &&
|
|
|
|
|
git -c i18n.commitencoding=utf8 commit -F msg &&
|
|
|
|
|
cat >msg <<-EOF &&
|
|
|
|
|
latin1
|
|
|
|
|
|
|
|
|
|
t${latin1_e}st
|
|
|
|
|
EOF
|
|
|
|
|
git add msg &&
|
|
|
|
|
git -c i18n.commitencoding=ISO-8859-1 commit -F msg
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'log --grep searches in log output encoding (utf8)' '
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
|
latin1
|
|
|
|
|
utf8
|
|
|
|
|
EOF
|
|
|
|
|
git log --encoding=utf8 --format=%s --grep=$utf8_e >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2014-07-21 22:09:27 +00:00
|
|
|
test_expect_success !MINGW 'log --grep searches in log output encoding (latin1)' '
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 20:59:58 +00:00
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
|
latin1
|
|
|
|
|
utf8
|
|
|
|
|
EOF
|
|
|
|
|
git log --encoding=ISO-8859-1 --format=%s --grep=$latin1_e >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2014-07-21 22:09:27 +00:00
|
|
|
test_expect_success !MINGW 'log --grep does not find non-reencoded values (utf8)' '
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 20:59:58 +00:00
|
|
|
git log --encoding=utf8 --format=%s --grep=$latin1_e >actual &&
|
2018-07-27 17:48:11 +00:00
|
|
|
test_must_be_empty actual
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 20:59:58 +00:00
|
|
|
'
|
|
|
|
|
|
2020-05-18 18:44:16 +00:00
|
|
|
test_expect_success 'log --grep does not find non-reencoded values (latin1)' '
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 20:59:58 +00:00
|
|
|
git log --encoding=ISO-8859-1 --format=%s --grep=$utf8_e >actual &&
|
2018-07-27 17:48:11 +00:00
|
|
|
test_must_be_empty actual
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 20:59:58 +00:00
|
|
|
'
|
|
|
|
|
|
2020-05-18 18:44:16 +00:00
|
|
|
triggers_undefined_behaviour () {
|
2024-04-06 00:08:59 +00:00
|
|
|
local engine="$1"
|
2020-05-18 18:44:16 +00:00
|
|
|
|
|
|
|
|
case $engine in
|
|
|
|
|
fixed)
|
|
|
|
|
if test -n "$have_reg_illseq" &&
|
|
|
|
|
! test_have_prereq LIBPCRE2
|
|
|
|
|
then
|
|
|
|
|
return 0
|
|
|
|
|
fi
|
|
|
|
|
;;
|
|
|
|
|
basic|extended)
|
|
|
|
|
if test -n "$have_reg_illseq"
|
|
|
|
|
then
|
|
|
|
|
return 0
|
|
|
|
|
fi
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
return 1
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mismatched_git_log () {
|
2024-04-06 00:08:59 +00:00
|
|
|
local pattern="$1"
|
2020-05-18 18:44:16 +00:00
|
|
|
|
|
|
|
|
LC_ALL=$is_IS_locale git log --encoding=ISO-8859-1 --format=%s \
|
|
|
|
|
--grep=$pattern
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-27 23:39:04 +00:00
|
|
|
for engine in fixed basic extended perl
|
|
|
|
|
do
|
|
|
|
|
prereq=
|
|
|
|
|
if test $engine = "perl"
|
|
|
|
|
then
|
2020-05-18 18:44:16 +00:00
|
|
|
prereq=PCRE
|
2019-06-27 23:39:04 +00:00
|
|
|
fi
|
|
|
|
|
force_regex=
|
|
|
|
|
if test $engine != "fixed"
|
|
|
|
|
then
|
2020-05-18 18:44:16 +00:00
|
|
|
force_regex='.*'
|
2019-06-27 23:39:04 +00:00
|
|
|
fi
|
|
|
|
|
|
2020-05-18 18:44:16 +00:00
|
|
|
test_expect_success $prereq "config grep.patternType=$engine" "
|
|
|
|
|
git config grep.patternType $engine
|
2019-06-27 23:39:04 +00:00
|
|
|
"
|
|
|
|
|
|
2020-05-18 18:44:16 +00:00
|
|
|
test_expect_success GETTEXT_LOCALE,$prereq "log --grep does not find non-reencoded values (latin1 + locale)" "
|
|
|
|
|
mismatched_git_log '$force_regex$utf8_e' >actual &&
|
2019-06-27 23:39:04 +00:00
|
|
|
test_must_be_empty actual
|
|
|
|
|
"
|
2020-05-18 18:44:16 +00:00
|
|
|
|
|
|
|
|
if ! triggers_undefined_behaviour $engine
|
|
|
|
|
then
|
|
|
|
|
test_expect_success !MINGW,GETTEXT_LOCALE,$prereq "log --grep searches in log output encoding (latin1 + locale)" "
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
|
latin1
|
|
|
|
|
utf8
|
|
|
|
|
EOF
|
|
|
|
|
mismatched_git_log '$force_regex$latin1_e' >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
"
|
|
|
|
|
|
|
|
|
|
test_expect_success GETTEXT_LOCALE,$prereq "log --grep does not die on invalid UTF-8 value (latin1 + locale + invalid needle)" "
|
|
|
|
|
mismatched_git_log '$force_regex$invalid_e' >actual &&
|
|
|
|
|
test_must_be_empty actual
|
|
|
|
|
"
|
|
|
|
|
fi
|
2019-06-27 23:39:04 +00:00
|
|
|
done
|
|
|
|
|
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 20:59:58 +00:00
|
|
|
test_done
|
