2007-03-28 02:08:28 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
2013-06-26 12:19:49 +02:00
|
|
|
# Copyright (c) 2009 Jens Lehmann
|
|
|
|
# Copyright (c) 2011 Alexey Shumkin (+ non-UTF-8 commit encoding tests)
|
|
|
|
|
2007-07-03 07:52:14 +02:00
|
|
|
test_description='git rev-list --pretty=format test'
|
2007-03-28 02:08:28 +02:00
|
|
|
|
|
|
|
. ./test-lib.sh
|
2012-12-17 23:56:49 +01:00
|
|
|
. "$TEST_DIRECTORY"/lib-terminal.sh
|
2007-03-28 02:08:28 +02:00
|
|
|
|
|
|
|
test_tick
|
2014-05-21 15:20:04 +02:00
|
|
|
# Tested non-UTF-8 encoding
|
|
|
|
test_encoding="ISO8859-1"
|
|
|
|
|
2013-07-05 14:01:48 +02:00
|
|
|
# String "added" in German
|
|
|
|
# (translated with Google Translate),
|
|
|
|
# encoded in UTF-8, used as a commit log message below.
|
2014-05-21 15:20:06 +02:00
|
|
|
added_utf8_part=$(printf "\303\274")
|
|
|
|
added_utf8_part_iso88591=$(echo "$added_utf8_part" | iconv -f utf-8 -t $test_encoding)
|
|
|
|
added=$(printf "added (hinzugef${added_utf8_part}gt) foo")
|
2014-05-21 15:20:04 +02:00
|
|
|
added_iso88591=$(echo "$added" | iconv -f utf-8 -t $test_encoding)
|
2013-06-26 12:19:49 +02:00
|
|
|
# same but "changed"
|
2014-05-21 15:20:06 +02:00
|
|
|
changed_utf8_part=$(printf "\303\244")
|
|
|
|
changed_utf8_part_iso88591=$(echo "$changed_utf8_part" | iconv -f utf-8 -t $test_encoding)
|
|
|
|
changed=$(printf "changed (ge${changed_utf8_part}ndert) foo")
|
2014-05-21 15:20:04 +02:00
|
|
|
changed_iso88591=$(echo "$changed" | iconv -f utf-8 -t $test_encoding)
|
2013-06-26 12:19:49 +02:00
|
|
|
|
2014-05-21 15:20:06 +02:00
|
|
|
# Count of char to truncate
|
|
|
|
# Number is chosen so, that non-ACSII characters
|
|
|
|
# (see $added_utf8_part and $changed_utf8_part)
|
|
|
|
# fall into truncated parts of appropriate words both from left and right
|
|
|
|
truncate_count=20
|
|
|
|
|
2007-03-28 02:08:28 +02:00
|
|
|
test_expect_success 'setup' '
|
2013-06-26 12:19:46 +02:00
|
|
|
: >foo &&
|
|
|
|
git add foo &&
|
2014-05-21 15:20:04 +02:00
|
|
|
git config i18n.commitEncoding $test_encoding &&
|
2013-09-02 16:44:54 +02:00
|
|
|
echo "$added_iso88591" | git commit -F - &&
|
2013-06-26 12:19:46 +02:00
|
|
|
head1=$(git rev-parse --verify HEAD) &&
|
|
|
|
head1_short=$(git rev-parse --verify --short $head1) &&
|
|
|
|
tree1=$(git rev-parse --verify HEAD:) &&
|
|
|
|
tree1_short=$(git rev-parse --verify --short $tree1) &&
|
2013-06-26 12:19:49 +02:00
|
|
|
echo "$changed" > foo &&
|
2013-09-02 16:44:54 +02:00
|
|
|
echo "$changed_iso88591" | git commit -a -F - &&
|
2013-06-26 12:19:46 +02:00
|
|
|
head2=$(git rev-parse --verify HEAD) &&
|
|
|
|
head2_short=$(git rev-parse --verify --short $head2) &&
|
|
|
|
tree2=$(git rev-parse --verify HEAD:) &&
|
2015-03-20 11:07:15 +01:00
|
|
|
tree2_short=$(git rev-parse --verify --short $tree2) &&
|
2013-06-26 12:19:49 +02:00
|
|
|
git config --unset i18n.commitEncoding
|
2007-03-28 02:08:28 +02:00
|
|
|
'
|
|
|
|
|
2013-07-05 14:01:48 +02:00
|
|
|
# usage: test_format name format_string [failure] <expected_output
|
2012-12-17 23:56:23 +01:00
|
|
|
test_format () {
|
2007-03-28 02:08:28 +02:00
|
|
|
cat >expect.$1
|
2013-07-05 14:01:48 +02:00
|
|
|
test_expect_${3:-success} "format $1" "
|
|
|
|
git rev-list --pretty=format:'$2' master >output.$1 &&
|
|
|
|
test_cmp expect.$1 output.$1
|
|
|
|
"
|
2007-03-28 02:08:28 +02:00
|
|
|
}
|
|
|
|
|
2012-12-17 23:56:49 +01:00
|
|
|
# Feed to --format to provide predictable colored sequences.
|
pretty: respect color settings for %C placeholders
The color placeholders have traditionally been
unconditional, showing colors even when git is not otherwise
configured to do so. This was not so bad for their original
use, which was on the command-line (and the user could
decide at that moment whether to add colors or not). But
these days we have configured formats via pretty.*, and
those should operate correctly in multiple contexts.
In 3082517 (log --format: teach %C(auto,black) to respect
color config, 2012-12-17), we gave an extended placeholder
that could be used to accomplish this. But it's rather
clunky to use, because you have to specify it individually
for each color (and their matching resets) in the format.
We shied away from just switching the default to auto,
because it is technically breaking backwards compatibility.
However, there's not really a use case for unconditional
colors. The most plausible reason you would want them is to
redirect "git log" output to a file. But there, the right
answer is --color=always, as it does the right thing both
with custom user-format colors and git-generated colors.
So let's switch to the more useful default. In the
off-chance that somebody really does find a use for
unconditional colors without wanting to enable the rest of
git's colors, we provide a new %C(always,...) to enable the
old behavior. And we can remind them of --color=always in
the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13 17:08:46 +02:00
|
|
|
BASIC_COLOR='%Credfoo%Creset'
|
|
|
|
COLOR='%C(red)foo%C(reset)'
|
2012-12-17 23:56:49 +01:00
|
|
|
AUTO_COLOR='%C(auto,red)foo%C(auto,reset)'
|
pretty: respect color settings for %C placeholders
The color placeholders have traditionally been
unconditional, showing colors even when git is not otherwise
configured to do so. This was not so bad for their original
use, which was on the command-line (and the user could
decide at that moment whether to add colors or not). But
these days we have configured formats via pretty.*, and
those should operate correctly in multiple contexts.
In 3082517 (log --format: teach %C(auto,black) to respect
color config, 2012-12-17), we gave an extended placeholder
that could be used to accomplish this. But it's rather
clunky to use, because you have to specify it individually
for each color (and their matching resets) in the format.
We shied away from just switching the default to auto,
because it is technically breaking backwards compatibility.
However, there's not really a use case for unconditional
colors. The most plausible reason you would want them is to
redirect "git log" output to a file. But there, the right
answer is --color=always, as it does the right thing both
with custom user-format colors and git-generated colors.
So let's switch to the more useful default. In the
off-chance that somebody really does find a use for
unconditional colors without wanting to enable the rest of
git's colors, we provide a new %C(always,...) to enable the
old behavior. And we can remind them of --color=always in
the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13 17:08:46 +02:00
|
|
|
ALWAYS_COLOR='%C(always,red)foo%C(always,reset)'
|
2012-12-17 23:56:49 +01:00
|
|
|
has_color () {
|
2017-07-13 16:58:41 +02:00
|
|
|
test_decode_color <"$1" >decoded &&
|
|
|
|
echo "<RED>foo<RESET>" >expect &&
|
|
|
|
test_cmp expect decoded
|
2012-12-17 23:56:49 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
has_no_color () {
|
|
|
|
echo foo >expect &&
|
|
|
|
test_cmp expect "$1"
|
|
|
|
}
|
|
|
|
|
2013-06-26 12:19:46 +02:00
|
|
|
test_format percent %%h <<EOF
|
|
|
|
commit $head2
|
2010-01-13 18:35:31 +01:00
|
|
|
%h
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head1
|
2010-01-13 18:35:31 +01:00
|
|
|
%h
|
|
|
|
EOF
|
|
|
|
|
2013-06-26 12:19:46 +02:00
|
|
|
test_format hash %H%n%h <<EOF
|
|
|
|
commit $head2
|
|
|
|
$head2
|
|
|
|
$head2_short
|
|
|
|
commit $head1
|
|
|
|
$head1
|
|
|
|
$head1_short
|
2007-03-28 02:08:28 +02:00
|
|
|
EOF
|
|
|
|
|
2013-06-26 12:19:46 +02:00
|
|
|
test_format tree %T%n%t <<EOF
|
|
|
|
commit $head2
|
|
|
|
$tree2
|
|
|
|
$tree2_short
|
|
|
|
commit $head1
|
|
|
|
$tree1
|
|
|
|
$tree1_short
|
2007-03-28 02:08:28 +02:00
|
|
|
EOF
|
|
|
|
|
2013-06-26 12:19:46 +02:00
|
|
|
test_format parents %P%n%p <<EOF
|
|
|
|
commit $head2
|
|
|
|
$head1
|
|
|
|
$head1_short
|
|
|
|
commit $head1
|
2007-03-28 22:33:37 +02:00
|
|
|
|
|
|
|
|
2007-03-28 02:08:28 +02:00
|
|
|
EOF
|
|
|
|
|
|
|
|
# we don't test relative here
|
2013-06-26 12:19:46 +02:00
|
|
|
test_format author %an%n%ae%n%ad%n%aD%n%at <<EOF
|
|
|
|
commit $head2
|
2007-03-28 02:08:28 +02:00
|
|
|
A U Thor
|
|
|
|
author@example.com
|
|
|
|
Thu Apr 7 15:13:13 2005 -0700
|
|
|
|
Thu, 7 Apr 2005 15:13:13 -0700
|
|
|
|
1112911993
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head1
|
2007-03-28 02:08:28 +02:00
|
|
|
A U Thor
|
|
|
|
author@example.com
|
|
|
|
Thu Apr 7 15:13:13 2005 -0700
|
|
|
|
Thu, 7 Apr 2005 15:13:13 -0700
|
|
|
|
1112911993
|
|
|
|
EOF
|
|
|
|
|
2013-06-26 12:19:46 +02:00
|
|
|
test_format committer %cn%n%ce%n%cd%n%cD%n%ct <<EOF
|
|
|
|
commit $head2
|
2007-03-28 02:08:28 +02:00
|
|
|
C O Mitter
|
|
|
|
committer@example.com
|
|
|
|
Thu Apr 7 15:13:13 2005 -0700
|
|
|
|
Thu, 7 Apr 2005 15:13:13 -0700
|
|
|
|
1112911993
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head1
|
2007-03-28 02:08:28 +02:00
|
|
|
C O Mitter
|
|
|
|
committer@example.com
|
|
|
|
Thu Apr 7 15:13:13 2005 -0700
|
|
|
|
Thu, 7 Apr 2005 15:13:13 -0700
|
|
|
|
1112911993
|
|
|
|
EOF
|
|
|
|
|
2013-06-26 12:19:46 +02:00
|
|
|
test_format encoding %e <<EOF
|
|
|
|
commit $head2
|
2014-05-21 15:20:04 +02:00
|
|
|
$test_encoding
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head1
|
2014-05-21 15:20:04 +02:00
|
|
|
$test_encoding
|
2007-03-28 02:08:28 +02:00
|
|
|
EOF
|
|
|
|
|
2013-06-26 12:19:50 +02:00
|
|
|
test_format subject %s <<EOF
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head2
|
2013-06-26 12:19:49 +02:00
|
|
|
$changed
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head1
|
2013-06-26 12:19:49 +02:00
|
|
|
$added
|
2007-03-28 02:08:28 +02:00
|
|
|
EOF
|
|
|
|
|
2014-05-21 15:20:06 +02:00
|
|
|
test_format subject-truncated "%<($truncate_count,trunc)%s" <<EOF
|
|
|
|
commit $head2
|
|
|
|
changed (ge${changed_utf8_part}ndert)..
|
|
|
|
commit $head1
|
|
|
|
added (hinzugef${added_utf8_part}gt..
|
|
|
|
EOF
|
|
|
|
|
2013-06-26 12:19:46 +02:00
|
|
|
test_format body %b <<EOF
|
|
|
|
commit $head2
|
|
|
|
commit $head1
|
2007-03-28 02:08:28 +02:00
|
|
|
EOF
|
|
|
|
|
2013-06-26 12:19:50 +02:00
|
|
|
test_format raw-body %B <<EOF
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head2
|
2013-06-26 12:19:49 +02:00
|
|
|
$changed
|
2010-03-25 03:51:52 +01:00
|
|
|
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head1
|
2013-06-26 12:19:49 +02:00
|
|
|
$added
|
2010-03-25 03:51:52 +01:00
|
|
|
|
|
|
|
EOF
|
|
|
|
|
2017-07-13 16:58:41 +02:00
|
|
|
test_expect_success 'basic colors' '
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
commit $head2
|
|
|
|
<RED>foo<GREEN>bar<BLUE>baz<RESET>xyzzy
|
|
|
|
EOF
|
|
|
|
format="%Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy" &&
|
pretty: respect color settings for %C placeholders
The color placeholders have traditionally been
unconditional, showing colors even when git is not otherwise
configured to do so. This was not so bad for their original
use, which was on the command-line (and the user could
decide at that moment whether to add colors or not). But
these days we have configured formats via pretty.*, and
those should operate correctly in multiple contexts.
In 3082517 (log --format: teach %C(auto,black) to respect
color config, 2012-12-17), we gave an extended placeholder
that could be used to accomplish this. But it's rather
clunky to use, because you have to specify it individually
for each color (and their matching resets) in the format.
We shied away from just switching the default to auto,
because it is technically breaking backwards compatibility.
However, there's not really a use case for unconditional
colors. The most plausible reason you would want them is to
redirect "git log" output to a file. But there, the right
answer is --color=always, as it does the right thing both
with custom user-format colors and git-generated colors.
So let's switch to the more useful default. In the
off-chance that somebody really does find a use for
unconditional colors without wanting to enable the rest of
git's colors, we provide a new %C(always,...) to enable the
old behavior. And we can remind them of --color=always in
the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13 17:08:46 +02:00
|
|
|
git rev-list --color --format="$format" -1 master >actual.raw &&
|
2017-07-13 16:58:41 +02:00
|
|
|
test_decode_color <actual.raw >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
2007-03-28 02:08:28 +02:00
|
|
|
|
2017-07-13 16:58:41 +02:00
|
|
|
test_expect_success 'advanced colors' '
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
commit $head2
|
|
|
|
<BOLD;RED;BYELLOW>foo<RESET>
|
|
|
|
EOF
|
|
|
|
format="%C(red yellow bold)foo%C(reset)" &&
|
pretty: respect color settings for %C placeholders
The color placeholders have traditionally been
unconditional, showing colors even when git is not otherwise
configured to do so. This was not so bad for their original
use, which was on the command-line (and the user could
decide at that moment whether to add colors or not). But
these days we have configured formats via pretty.*, and
those should operate correctly in multiple contexts.
In 3082517 (log --format: teach %C(auto,black) to respect
color config, 2012-12-17), we gave an extended placeholder
that could be used to accomplish this. But it's rather
clunky to use, because you have to specify it individually
for each color (and their matching resets) in the format.
We shied away from just switching the default to auto,
because it is technically breaking backwards compatibility.
However, there's not really a use case for unconditional
colors. The most plausible reason you would want them is to
redirect "git log" output to a file. But there, the right
answer is --color=always, as it does the right thing both
with custom user-format colors and git-generated colors.
So let's switch to the more useful default. In the
off-chance that somebody really does find a use for
unconditional colors without wanting to enable the rest of
git's colors, we provide a new %C(always,...) to enable the
old behavior. And we can remind them of --color=always in
the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13 17:08:46 +02:00
|
|
|
git rev-list --color --format="$format" -1 master >actual.raw &&
|
2017-07-13 16:58:41 +02:00
|
|
|
test_decode_color <actual.raw >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
expand --pretty=format color options
Currently, the only colors available to --pretty=format
users are red, green, and blue. Rather than expand it with a
few new colors, this patch makes the usual config color
syntax available, including more colors, backgrounds, and
attributes.
Because colors are no longer bounded to a single word (e.g.,
%Cred), this uses a more advanced syntax that features a
beginning and end delimiter (but the old syntax still
works). So you can now do:
git log --pretty=tformat:'%C(yellow)%h%C(reset) %s'
to emulate --pretty=oneline, or even
git log --pretty=tformat:'%C(cyan magenta bold)%s%C(reset)'
if you want to relive the awesomeness of 4-color CGA.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:38:46 +01:00
|
|
|
|
pretty: respect color settings for %C placeholders
The color placeholders have traditionally been
unconditional, showing colors even when git is not otherwise
configured to do so. This was not so bad for their original
use, which was on the command-line (and the user could
decide at that moment whether to add colors or not). But
these days we have configured formats via pretty.*, and
those should operate correctly in multiple contexts.
In 3082517 (log --format: teach %C(auto,black) to respect
color config, 2012-12-17), we gave an extended placeholder
that could be used to accomplish this. But it's rather
clunky to use, because you have to specify it individually
for each color (and their matching resets) in the format.
We shied away from just switching the default to auto,
because it is technically breaking backwards compatibility.
However, there's not really a use case for unconditional
colors. The most plausible reason you would want them is to
redirect "git log" output to a file. But there, the right
answer is --color=always, as it does the right thing both
with custom user-format colors and git-generated colors.
So let's switch to the more useful default. In the
off-chance that somebody really does find a use for
unconditional colors without wanting to enable the rest of
git's colors, we provide a new %C(always,...) to enable the
old behavior. And we can remind them of --color=always in
the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13 17:08:46 +02:00
|
|
|
for spec in \
|
|
|
|
"%Cred:$BASIC_COLOR" \
|
|
|
|
"%C(...):$COLOR" \
|
|
|
|
"%C(auto,...):$AUTO_COLOR"
|
|
|
|
do
|
|
|
|
desc=${spec%%:*}
|
|
|
|
color=${spec#*:}
|
|
|
|
test_expect_success "$desc does not enable color by default" '
|
|
|
|
git log --format=$color -1 >actual &&
|
|
|
|
has_no_color actual
|
|
|
|
'
|
2012-12-17 23:56:49 +01:00
|
|
|
|
pretty: respect color settings for %C placeholders
The color placeholders have traditionally been
unconditional, showing colors even when git is not otherwise
configured to do so. This was not so bad for their original
use, which was on the command-line (and the user could
decide at that moment whether to add colors or not). But
these days we have configured formats via pretty.*, and
those should operate correctly in multiple contexts.
In 3082517 (log --format: teach %C(auto,black) to respect
color config, 2012-12-17), we gave an extended placeholder
that could be used to accomplish this. But it's rather
clunky to use, because you have to specify it individually
for each color (and their matching resets) in the format.
We shied away from just switching the default to auto,
because it is technically breaking backwards compatibility.
However, there's not really a use case for unconditional
colors. The most plausible reason you would want them is to
redirect "git log" output to a file. But there, the right
answer is --color=always, as it does the right thing both
with custom user-format colors and git-generated colors.
So let's switch to the more useful default. In the
off-chance that somebody really does find a use for
unconditional colors without wanting to enable the rest of
git's colors, we provide a new %C(always,...) to enable the
old behavior. And we can remind them of --color=always in
the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13 17:08:46 +02:00
|
|
|
test_expect_success "$desc enables colors for color.diff" '
|
|
|
|
git -c color.diff=always log --format=$color -1 >actual &&
|
|
|
|
has_color actual
|
|
|
|
'
|
2012-12-17 23:56:49 +01:00
|
|
|
|
pretty: respect color settings for %C placeholders
The color placeholders have traditionally been
unconditional, showing colors even when git is not otherwise
configured to do so. This was not so bad for their original
use, which was on the command-line (and the user could
decide at that moment whether to add colors or not). But
these days we have configured formats via pretty.*, and
those should operate correctly in multiple contexts.
In 3082517 (log --format: teach %C(auto,black) to respect
color config, 2012-12-17), we gave an extended placeholder
that could be used to accomplish this. But it's rather
clunky to use, because you have to specify it individually
for each color (and their matching resets) in the format.
We shied away from just switching the default to auto,
because it is technically breaking backwards compatibility.
However, there's not really a use case for unconditional
colors. The most plausible reason you would want them is to
redirect "git log" output to a file. But there, the right
answer is --color=always, as it does the right thing both
with custom user-format colors and git-generated colors.
So let's switch to the more useful default. In the
off-chance that somebody really does find a use for
unconditional colors without wanting to enable the rest of
git's colors, we provide a new %C(always,...) to enable the
old behavior. And we can remind them of --color=always in
the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13 17:08:46 +02:00
|
|
|
test_expect_success "$desc enables colors for color.ui" '
|
|
|
|
git -c color.ui=always log --format=$color -1 >actual &&
|
|
|
|
has_color actual
|
|
|
|
'
|
2012-12-17 23:56:49 +01:00
|
|
|
|
pretty: respect color settings for %C placeholders
The color placeholders have traditionally been
unconditional, showing colors even when git is not otherwise
configured to do so. This was not so bad for their original
use, which was on the command-line (and the user could
decide at that moment whether to add colors or not). But
these days we have configured formats via pretty.*, and
those should operate correctly in multiple contexts.
In 3082517 (log --format: teach %C(auto,black) to respect
color config, 2012-12-17), we gave an extended placeholder
that could be used to accomplish this. But it's rather
clunky to use, because you have to specify it individually
for each color (and their matching resets) in the format.
We shied away from just switching the default to auto,
because it is technically breaking backwards compatibility.
However, there's not really a use case for unconditional
colors. The most plausible reason you would want them is to
redirect "git log" output to a file. But there, the right
answer is --color=always, as it does the right thing both
with custom user-format colors and git-generated colors.
So let's switch to the more useful default. In the
off-chance that somebody really does find a use for
unconditional colors without wanting to enable the rest of
git's colors, we provide a new %C(always,...) to enable the
old behavior. And we can remind them of --color=always in
the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13 17:08:46 +02:00
|
|
|
test_expect_success "$desc respects --color" '
|
|
|
|
git log --format=$color -1 --color >actual &&
|
|
|
|
has_color actual
|
|
|
|
'
|
2012-12-17 23:56:49 +01:00
|
|
|
|
pretty: respect color settings for %C placeholders
The color placeholders have traditionally been
unconditional, showing colors even when git is not otherwise
configured to do so. This was not so bad for their original
use, which was on the command-line (and the user could
decide at that moment whether to add colors or not). But
these days we have configured formats via pretty.*, and
those should operate correctly in multiple contexts.
In 3082517 (log --format: teach %C(auto,black) to respect
color config, 2012-12-17), we gave an extended placeholder
that could be used to accomplish this. But it's rather
clunky to use, because you have to specify it individually
for each color (and their matching resets) in the format.
We shied away from just switching the default to auto,
because it is technically breaking backwards compatibility.
However, there's not really a use case for unconditional
colors. The most plausible reason you would want them is to
redirect "git log" output to a file. But there, the right
answer is --color=always, as it does the right thing both
with custom user-format colors and git-generated colors.
So let's switch to the more useful default. In the
off-chance that somebody really does find a use for
unconditional colors without wanting to enable the rest of
git's colors, we provide a new %C(always,...) to enable the
old behavior. And we can remind them of --color=always in
the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13 17:08:46 +02:00
|
|
|
test_expect_success "$desc respects --no-color" '
|
|
|
|
git -c color.ui=always log --format=$color -1 --no-color >actual &&
|
2012-12-17 23:56:49 +01:00
|
|
|
has_no_color actual
|
pretty: respect color settings for %C placeholders
The color placeholders have traditionally been
unconditional, showing colors even when git is not otherwise
configured to do so. This was not so bad for their original
use, which was on the command-line (and the user could
decide at that moment whether to add colors or not). But
these days we have configured formats via pretty.*, and
those should operate correctly in multiple contexts.
In 3082517 (log --format: teach %C(auto,black) to respect
color config, 2012-12-17), we gave an extended placeholder
that could be used to accomplish this. But it's rather
clunky to use, because you have to specify it individually
for each color (and their matching resets) in the format.
We shied away from just switching the default to auto,
because it is technically breaking backwards compatibility.
However, there's not really a use case for unconditional
colors. The most plausible reason you would want them is to
redirect "git log" output to a file. But there, the right
answer is --color=always, as it does the right thing both
with custom user-format colors and git-generated colors.
So let's switch to the more useful default. In the
off-chance that somebody really does find a use for
unconditional colors without wanting to enable the rest of
git's colors, we provide a new %C(always,...) to enable the
old behavior. And we can remind them of --color=always in
the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13 17:08:46 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY "$desc respects --color=auto (stdout is tty)" '
|
|
|
|
test_terminal env TERM=vt100 \
|
|
|
|
git log --format=$color -1 --color=auto >actual &&
|
|
|
|
has_color actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success "$desc respects --color=auto (stdout not tty)" '
|
|
|
|
(
|
|
|
|
TERM=vt100 && export TERM &&
|
|
|
|
git log --format=$color -1 --color=auto >actual &&
|
|
|
|
has_no_color actual
|
|
|
|
)
|
|
|
|
'
|
|
|
|
done
|
|
|
|
|
|
|
|
test_expect_success '%C(always,...) enables color even without tty' '
|
|
|
|
git log --format=$ALWAYS_COLOR -1 >actual &&
|
|
|
|
has_color actual
|
2012-12-17 23:56:49 +01:00
|
|
|
'
|
|
|
|
|
2016-05-27 05:46:10 +02:00
|
|
|
test_expect_success '%C(auto) respects --color' '
|
2017-07-13 16:58:41 +02:00
|
|
|
git log --color --format="%C(auto)%H" -1 >actual.raw &&
|
|
|
|
test_decode_color <actual.raw >actual &&
|
|
|
|
echo "<YELLOW>$(git rev-parse HEAD)<RESET>" >expect &&
|
2016-05-27 05:46:10 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '%C(auto) respects --no-color' '
|
|
|
|
git log --no-color --format="%C(auto)%H" -1 >actual &&
|
|
|
|
git rev-parse HEAD >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2017-07-13 17:07:30 +02:00
|
|
|
test_expect_success 'rev-list %C(auto,...) respects --color' '
|
|
|
|
git rev-list --color --format="%C(auto,green)foo%C(auto,reset)" \
|
|
|
|
-1 HEAD >actual.raw &&
|
|
|
|
test_decode_color <actual.raw >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
commit $(git rev-parse HEAD)
|
|
|
|
<GREEN>foo<RESET>
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2014-05-21 15:20:04 +02:00
|
|
|
iconv -f utf-8 -t $test_encoding > commit-msg <<EOF
|
2007-03-28 23:08:36 +02:00
|
|
|
Test printing of complex bodies
|
|
|
|
|
|
|
|
This commit message is much longer than the others,
|
2014-05-21 15:20:04 +02:00
|
|
|
and it will be encoded in $test_encoding. We should therefore
|
|
|
|
include an ISO8859 character: ¡bueno!
|
2007-03-28 23:08:36 +02:00
|
|
|
EOF
|
2013-06-26 12:19:46 +02:00
|
|
|
|
2007-03-28 23:08:36 +02:00
|
|
|
test_expect_success 'setup complex body' '
|
2014-05-21 15:20:04 +02:00
|
|
|
git config i18n.commitencoding $test_encoding &&
|
2013-06-26 12:19:46 +02:00
|
|
|
echo change2 >foo && git commit -a -F commit-msg &&
|
|
|
|
head3=$(git rev-parse --verify HEAD) &&
|
2013-07-05 14:01:49 +02:00
|
|
|
head3_short=$(git rev-parse --short $head3)
|
2007-03-28 23:08:36 +02:00
|
|
|
'
|
|
|
|
|
2013-06-26 12:19:46 +02:00
|
|
|
test_format complex-encoding %e <<EOF
|
|
|
|
commit $head3
|
2014-05-21 15:20:04 +02:00
|
|
|
$test_encoding
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head2
|
2014-05-21 15:20:04 +02:00
|
|
|
$test_encoding
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head1
|
2014-05-21 15:20:04 +02:00
|
|
|
$test_encoding
|
2007-03-28 23:08:36 +02:00
|
|
|
EOF
|
|
|
|
|
2013-06-26 12:19:50 +02:00
|
|
|
test_format complex-subject %s <<EOF
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head3
|
2007-03-28 23:08:36 +02:00
|
|
|
Test printing of complex bodies
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head2
|
2013-07-05 14:01:49 +02:00
|
|
|
$changed_iso88591
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head1
|
2013-07-05 14:01:49 +02:00
|
|
|
$added_iso88591
|
2007-03-28 23:08:36 +02:00
|
|
|
EOF
|
|
|
|
|
2014-05-21 15:20:07 +02:00
|
|
|
test_format complex-subject-trunc "%<($truncate_count,trunc)%s" <<EOF
|
2014-05-21 15:20:06 +02:00
|
|
|
commit $head3
|
|
|
|
Test printing of c..
|
|
|
|
commit $head2
|
|
|
|
changed (ge${changed_utf8_part_iso88591}ndert)..
|
|
|
|
commit $head1
|
|
|
|
added (hinzugef${added_utf8_part_iso88591}gt..
|
|
|
|
EOF
|
|
|
|
|
2014-05-21 15:20:07 +02:00
|
|
|
test_format complex-subject-mtrunc "%<($truncate_count,mtrunc)%s" <<EOF
|
2014-05-21 15:20:06 +02:00
|
|
|
commit $head3
|
|
|
|
Test prin..ex bodies
|
|
|
|
commit $head2
|
|
|
|
changed (..dert) foo
|
|
|
|
commit $head1
|
|
|
|
added (hi..f${added_utf8_part_iso88591}gt) foo
|
|
|
|
EOF
|
|
|
|
|
2014-05-21 15:20:07 +02:00
|
|
|
test_format complex-subject-ltrunc "%<($truncate_count,ltrunc)%s" <<EOF
|
2014-05-21 15:20:06 +02:00
|
|
|
commit $head3
|
|
|
|
.. of complex bodies
|
|
|
|
commit $head2
|
|
|
|
..ged (ge${changed_utf8_part_iso88591}ndert) foo
|
|
|
|
commit $head1
|
|
|
|
.. (hinzugef${added_utf8_part_iso88591}gt) foo
|
|
|
|
EOF
|
|
|
|
|
2013-07-05 14:01:49 +02:00
|
|
|
test_expect_success 'prepare expected messages (for test %b)' '
|
|
|
|
cat <<-EOF >expected.utf-8 &&
|
|
|
|
commit $head3
|
|
|
|
This commit message is much longer than the others,
|
2014-05-21 15:20:04 +02:00
|
|
|
and it will be encoded in $test_encoding. We should therefore
|
|
|
|
include an ISO8859 character: ¡bueno!
|
2013-07-05 14:01:49 +02:00
|
|
|
|
|
|
|
commit $head2
|
|
|
|
commit $head1
|
|
|
|
EOF
|
2014-05-21 15:20:04 +02:00
|
|
|
iconv -f utf-8 -t $test_encoding expected.utf-8 >expected.ISO8859-1
|
2013-07-05 14:01:49 +02:00
|
|
|
'
|
|
|
|
|
2014-05-21 15:20:04 +02:00
|
|
|
test_format complex-body %b <expected.ISO8859-1
|
2007-03-28 23:08:36 +02:00
|
|
|
|
2013-07-05 14:01:49 +02:00
|
|
|
# Git uses i18n.commitEncoding if no i18n.logOutputEncoding set
|
|
|
|
# so unset i18n.commitEncoding to test encoding conversion
|
|
|
|
git config --unset i18n.commitEncoding
|
|
|
|
|
|
|
|
test_format complex-subject-commitencoding-unset %s <<EOF
|
|
|
|
commit $head3
|
|
|
|
Test printing of complex bodies
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head2
|
2013-07-05 14:01:49 +02:00
|
|
|
$changed
|
2013-06-26 12:19:46 +02:00
|
|
|
commit $head1
|
2013-07-05 14:01:49 +02:00
|
|
|
$added
|
2007-03-28 23:08:36 +02:00
|
|
|
EOF
|
|
|
|
|
2014-05-21 15:20:06 +02:00
|
|
|
test_format complex-subject-commitencoding-unset-trunc "%<($truncate_count,trunc)%s" <<EOF
|
|
|
|
commit $head3
|
|
|
|
Test printing of c..
|
|
|
|
commit $head2
|
|
|
|
changed (ge${changed_utf8_part}ndert)..
|
|
|
|
commit $head1
|
|
|
|
added (hinzugef${added_utf8_part}gt..
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_format complex-subject-commitencoding-unset-mtrunc "%<($truncate_count,mtrunc)%s" <<EOF
|
|
|
|
commit $head3
|
|
|
|
Test prin..ex bodies
|
|
|
|
commit $head2
|
|
|
|
changed (..dert) foo
|
|
|
|
commit $head1
|
|
|
|
added (hi..f${added_utf8_part}gt) foo
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_format complex-subject-commitencoding-unset-ltrunc "%<($truncate_count,ltrunc)%s" <<EOF
|
|
|
|
commit $head3
|
|
|
|
.. of complex bodies
|
|
|
|
commit $head2
|
|
|
|
..ged (ge${changed_utf8_part}ndert) foo
|
|
|
|
commit $head1
|
|
|
|
.. (hinzugef${added_utf8_part}gt) foo
|
|
|
|
EOF
|
|
|
|
|
2013-07-05 14:01:49 +02:00
|
|
|
test_format complex-body-commitencoding-unset %b <expected.utf-8
|
|
|
|
|
2010-10-07 20:25:43 +02:00
|
|
|
test_expect_success '%x00 shows NUL' '
|
2013-06-26 12:19:46 +02:00
|
|
|
echo >expect commit $head3 &&
|
2010-10-07 20:25:43 +02:00
|
|
|
echo >>expect fooQbar &&
|
|
|
|
git rev-list -1 --format=foo%x00bar HEAD >actual.nul &&
|
|
|
|
nul_to_q <actual.nul >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2008-08-29 02:54:59 +02:00
|
|
|
test_expect_success '%ad respects --date=' '
|
|
|
|
echo 2005-04-07 >expect.ad-short &&
|
|
|
|
git log -1 --date=short --pretty=tformat:%ad >output.ad-short master &&
|
|
|
|
test_cmp expect.ad-short output.ad-short
|
|
|
|
'
|
|
|
|
|
2008-01-06 13:21:07 +01:00
|
|
|
test_expect_success 'empty email' '
|
|
|
|
test_tick &&
|
|
|
|
C=$(GIT_AUTHOR_EMAIL= git commit-tree HEAD^{tree} </dev/null) &&
|
|
|
|
A=$(git show --pretty=format:%an,%ae,%ad%n -s $C) &&
|
2015-03-20 11:09:00 +01:00
|
|
|
verbose test "$A" = "A U Thor,,Thu Apr 7 15:14:13 2005 -0700"
|
2008-01-06 13:21:07 +01:00
|
|
|
'
|
|
|
|
|
2009-10-05 08:43:32 +02:00
|
|
|
test_expect_success 'del LF before empty (1)' '
|
|
|
|
git show -s --pretty=format:"%s%n%-b%nThanks%n" HEAD^^ >actual &&
|
2012-04-11 13:24:01 +02:00
|
|
|
test_line_count = 2 actual
|
2009-10-05 08:43:32 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'del LF before empty (2)' '
|
|
|
|
git show -s --pretty=format:"%s%n%-b%nThanks%n" HEAD >actual &&
|
2012-04-11 13:24:01 +02:00
|
|
|
test_line_count = 6 actual &&
|
2009-10-05 08:43:32 +02:00
|
|
|
grep "^$" actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'add LF before non-empty (1)' '
|
|
|
|
git show -s --pretty=format:"%s%+b%nThanks%n" HEAD^^ >actual &&
|
2012-04-11 13:24:01 +02:00
|
|
|
test_line_count = 2 actual
|
2009-10-05 08:43:32 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'add LF before non-empty (2)' '
|
|
|
|
git show -s --pretty=format:"%s%+b%nThanks%n" HEAD >actual &&
|
2012-04-11 13:24:01 +02:00
|
|
|
test_line_count = 6 actual &&
|
2009-10-05 08:43:32 +02:00
|
|
|
grep "^$" actual
|
|
|
|
'
|
|
|
|
|
2010-06-14 18:12:29 +02:00
|
|
|
test_expect_success 'add SP before non-empty (1)' '
|
|
|
|
git show -s --pretty=format:"%s% bThanks" HEAD^^ >actual &&
|
2013-06-26 12:19:49 +02:00
|
|
|
test $(wc -w <actual) = 3
|
2010-06-14 18:12:29 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'add SP before non-empty (2)' '
|
|
|
|
git show -s --pretty=format:"%s% sThanks" HEAD^^ >actual &&
|
2013-06-26 12:19:49 +02:00
|
|
|
test $(wc -w <actual) = 6
|
2010-06-14 18:12:29 +02:00
|
|
|
'
|
|
|
|
|
2010-05-04 05:18:57 +02:00
|
|
|
test_expect_success '--abbrev' '
|
|
|
|
echo SHORT SHORT SHORT >expect2 &&
|
|
|
|
echo LONG LONG LONG >expect3 &&
|
|
|
|
git log -1 --format="%h %h %h" HEAD >actual1 &&
|
|
|
|
git log -1 --abbrev=5 --format="%h %h %h" HEAD >actual2 &&
|
|
|
|
git log -1 --abbrev=5 --format="%H %H %H" HEAD >actual3 &&
|
|
|
|
sed -e "s/$_x40/LONG/g" -e "s/$_x05/SHORT/g" <actual2 >fuzzy2 &&
|
|
|
|
sed -e "s/$_x40/LONG/g" -e "s/$_x05/SHORT/g" <actual3 >fuzzy3 &&
|
|
|
|
test_cmp expect2 fuzzy2 &&
|
|
|
|
test_cmp expect3 fuzzy3 &&
|
|
|
|
! test_cmp actual1 actual2
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '%H is not affected by --abbrev-commit' '
|
|
|
|
git log -1 --format=%H --abbrev-commit --abbrev=20 HEAD >actual &&
|
|
|
|
len=$(wc -c <actual) &&
|
|
|
|
test $len = 41
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '%h is not affected by --abbrev-commit' '
|
|
|
|
git log -1 --format=%h --abbrev-commit --abbrev=20 HEAD >actual &&
|
|
|
|
len=$(wc -c <actual) &&
|
|
|
|
test $len = 21
|
|
|
|
'
|
|
|
|
|
2009-10-19 17:48:10 +02:00
|
|
|
test_expect_success '"%h %gD: %gs" is same as git-reflog' '
|
|
|
|
git reflog >expect &&
|
|
|
|
git log -g --format="%h %gD: %gs" >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '"%h %gD: %gs" is same as git-reflog (with date)' '
|
|
|
|
git reflog --date=raw >expect &&
|
|
|
|
git log -g --format="%h %gD: %gs" --date=raw >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2010-05-04 05:18:57 +02:00
|
|
|
test_expect_success '"%h %gD: %gs" is same as git-reflog (with --abbrev)' '
|
|
|
|
git reflog --abbrev=13 --date=raw >expect &&
|
|
|
|
git log -g --abbrev=13 --format="%h %gD: %gs" --date=raw >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2009-10-19 17:48:10 +02:00
|
|
|
test_expect_success '%gd shortens ref name' '
|
|
|
|
echo "master@{0}" >expect.gd-short &&
|
|
|
|
git log -g -1 --format=%gd refs/heads/master >actual.gd-short &&
|
|
|
|
test_cmp expect.gd-short actual.gd-short
|
|
|
|
'
|
|
|
|
|
2011-12-16 12:40:24 +01:00
|
|
|
test_expect_success 'reflog identity' '
|
|
|
|
echo "C O Mitter:committer@example.com" >expect &&
|
|
|
|
git log -g -1 --format="%gn:%ge" >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2010-03-21 15:40:16 +01:00
|
|
|
test_expect_success 'oneline with empty message' '
|
|
|
|
git commit -m "dummy" --allow-empty &&
|
|
|
|
git commit -m "dummy" --allow-empty &&
|
|
|
|
git filter-branch --msg-filter "sed -e s/dummy//" HEAD^^.. &&
|
2010-04-17 04:29:18 +02:00
|
|
|
git rev-list --oneline HEAD >test.txt &&
|
2012-04-11 13:24:01 +02:00
|
|
|
test_line_count = 5 test.txt &&
|
|
|
|
git rev-list --oneline --graph HEAD >testg.txt &&
|
|
|
|
test_line_count = 5 testg.txt
|
2010-03-21 15:40:16 +01:00
|
|
|
'
|
|
|
|
|
2012-05-22 08:12:20 +02:00
|
|
|
test_expect_success 'single-character name is parsed correctly' '
|
|
|
|
git commit --author="a <a@example.com>" --allow-empty -m foo &&
|
|
|
|
echo "a <a@example.com>" >expect &&
|
|
|
|
git log -1 --format="%an <%ae>" >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2014-06-25 23:42:17 +02:00
|
|
|
test_expect_success 'unused %G placeholders are passed through' '
|
|
|
|
echo "%GX %G" >expect &&
|
|
|
|
git log -1 --format="%GX %G" >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2007-03-28 02:08:28 +02:00
|
|
|
test_done
|