2010-06-29 07:47:08 +00:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# Copyright (c) 2010 Nazri Ramliy
|
|
|
|
#
|
|
|
|
|
|
|
|
test_description='Test for "git log --decorate" colors'
|
|
|
|
|
2020-11-18 23:44:27 +00:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
tests: mark tests relying on the current default for `init.defaultBranch`
In addition to the manual adjustment to let the `linux-gcc` CI job run
the test suite with `master` and then with `main`, this patch makes sure
that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts
that currently rely on the initial branch name being `master by default.
To determine which test scripts to mark up, the first step was to
force-set the default branch name to `master` in
- all test scripts that contain the keyword `master`,
- t4211, which expects `t/t4211/history.export` with a hard-coded ref to
initialize the default branch,
- t5560 because it sources `t/t556x_common` which uses `master`,
- t8002 and t8012 because both source `t/annotate-tests.sh` which also
uses `master`)
This trick was performed by this command:
$ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' $(git grep -l master t/t[0-9]*.sh) \
t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh
After that, careful, manual inspection revealed that some of the test
scripts containing the needle `master` do not actually rely on a
specific default branch name: either they mention `master` only in a
comment, or they initialize that branch specificially, or they do not
actually refer to the current default branch. Therefore, the
aforementioned modification was undone in those test scripts thusly:
$ git checkout HEAD -- \
t/t0027-auto-crlf.sh t/t0060-path-utils.sh \
t/t1011-read-tree-sparse-checkout.sh \
t/t1305-config-include.sh t/t1309-early-config.sh \
t/t1402-check-ref-format.sh t/t1450-fsck.sh \
t/t2024-checkout-dwim.sh \
t/t2106-update-index-assume-unchanged.sh \
t/t3040-subprojects-basic.sh t/t3301-notes.sh \
t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \
t/t3436-rebase-more-options.sh \
t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \
t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \
t/t5511-refspec.sh t/t5526-fetch-submodules.sh \
t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \
t/t5548-push-porcelain.sh \
t/t5552-skipping-fetch-negotiator.sh \
t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \
t/t5614-clone-submodules-shallow.sh \
t/t7508-status.sh t/t7606-merge-custom.sh \
t/t9302-fast-import-unpack-limit.sh
We excluded one set of test scripts in these commands, though: the range
of `git p4` tests. The reason? `git p4` stores the (foreign) remote
branch in the branch called `p4/master`, which is obviously not the
default branch. Manual analysis revealed that only five of these tests
actually require a specific default branch name to pass; They were
modified thusly:
$ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' t/t980[0167]*.sh t/t9811*.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18 23:44:19 +00:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2022-04-13 20:01:48 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2010-06-29 07:47:08 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_expect_success setup '
|
|
|
|
git config diff.color.commit yellow &&
|
|
|
|
git config color.decorate.branch green &&
|
|
|
|
git config color.decorate.remoteBranch red &&
|
|
|
|
git config color.decorate.tag "reverse bold yellow" &&
|
|
|
|
git config color.decorate.stash magenta &&
|
|
|
|
git config color.decorate.HEAD cyan &&
|
|
|
|
|
2017-07-13 14:58:41 +00:00
|
|
|
c_reset="<RESET>" &&
|
2010-06-29 07:47:08 +00:00
|
|
|
|
2017-07-13 14:58:41 +00:00
|
|
|
c_commit="<YELLOW>" &&
|
|
|
|
c_branch="<GREEN>" &&
|
|
|
|
c_remoteBranch="<RED>" &&
|
|
|
|
c_tag="<BOLD;REVERSE;YELLOW>" &&
|
|
|
|
c_stash="<MAGENTA>" &&
|
|
|
|
c_HEAD="<CYAN>" &&
|
2010-06-29 07:47:08 +00:00
|
|
|
|
|
|
|
test_commit A &&
|
|
|
|
git clone . other &&
|
|
|
|
(
|
|
|
|
cd other &&
|
|
|
|
test_commit A1
|
|
|
|
) &&
|
|
|
|
|
|
|
|
git remote add -f other ./other &&
|
|
|
|
test_commit B &&
|
|
|
|
git tag v1.0 &&
|
|
|
|
echo >>A.t &&
|
|
|
|
git stash save Changes to A.t
|
|
|
|
'
|
|
|
|
|
|
|
|
cat >expected <<EOF
|
2016-07-09 12:49:49 +00:00
|
|
|
${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_HEAD}HEAD ->\
|
2020-11-18 23:44:27 +00:00
|
|
|
${c_reset}${c_branch}main${c_reset}${c_commit},\
|
log --decorate: do not leak "commit" color into the next item
In "git log --decorate", you would see the commit header like this:
commit ... (HEAD, jc/decorate-leaky-separator-color)
where "commit ... (" is painted in color.diff.commit, "HEAD" in
color.decorate.head, ", " in color.diff.commit, the branch name in
color.decorate.branch and then closing ")" in color.diff.commit.
If you wanted to paint the HEAD and local branch name in the same
color as the body text (perhaps because cyan and green are too faint
on a black-on-white terminal to be readable), you would not want to
have to say
[color "decorate"]
head = black
branch = black
because that you would not be able to reuse same configuration on a
white-on-black terminal. You would naively expect
[color "decorate"]
head = normal
branch = normal
to work, but unfortunately it does not. It paints the string "HEAD"
and the branch name in the same color as the opening parenthesis or
comma between the decoration elements. This is because the code
forgets to reset the color after printing the "prefix" in its own
color.
It theoretically is possible that some people were expecting and
relying on that the attribute set as the "diff.commit" color, which
is used to draw these opening parenthesis and inter-item comma, is
inherited by the drawing of branch names, but it is not how the
coloring works everywhere else.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-04 19:07:12 +00:00
|
|
|
${c_reset}${c_tag}tag: v1.0${c_reset}${c_commit},\
|
2015-03-10 13:53:21 +00:00
|
|
|
${c_reset}${c_tag}tag: B${c_reset}${c_commit})${c_reset} B
|
log --decorate: do not leak "commit" color into the next item
In "git log --decorate", you would see the commit header like this:
commit ... (HEAD, jc/decorate-leaky-separator-color)
where "commit ... (" is painted in color.diff.commit, "HEAD" in
color.decorate.head, ", " in color.diff.commit, the branch name in
color.decorate.branch and then closing ")" in color.diff.commit.
If you wanted to paint the HEAD and local branch name in the same
color as the body text (perhaps because cyan and green are too faint
on a black-on-white terminal to be readable), you would not want to
have to say
[color "decorate"]
head = black
branch = black
because that you would not be able to reuse same configuration on a
white-on-black terminal. You would naively expect
[color "decorate"]
head = normal
branch = normal
to work, but unfortunately it does not. It paints the string "HEAD"
and the branch name in the same color as the opening parenthesis or
comma between the decoration elements. This is because the code
forgets to reset the color after printing the "prefix" in its own
color.
It theoretically is possible that some people were expecting and
relying on that the attribute set as the "diff.commit" color, which
is used to draw these opening parenthesis and inter-item comma, is
inherited by the drawing of branch names, but it is not how the
coloring works everywhere else.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-04 19:07:12 +00:00
|
|
|
${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_tag}tag: A1${c_reset}${c_commit},\
|
2020-11-18 23:44:27 +00:00
|
|
|
${c_reset}${c_remoteBranch}other/main${c_reset}${c_commit})${c_reset} A1
|
log --decorate: do not leak "commit" color into the next item
In "git log --decorate", you would see the commit header like this:
commit ... (HEAD, jc/decorate-leaky-separator-color)
where "commit ... (" is painted in color.diff.commit, "HEAD" in
color.decorate.head, ", " in color.diff.commit, the branch name in
color.decorate.branch and then closing ")" in color.diff.commit.
If you wanted to paint the HEAD and local branch name in the same
color as the body text (perhaps because cyan and green are too faint
on a black-on-white terminal to be readable), you would not want to
have to say
[color "decorate"]
head = black
branch = black
because that you would not be able to reuse same configuration on a
white-on-black terminal. You would naively expect
[color "decorate"]
head = normal
branch = normal
to work, but unfortunately it does not. It paints the string "HEAD"
and the branch name in the same color as the opening parenthesis or
comma between the decoration elements. This is because the code
forgets to reset the color after printing the "prefix" in its own
color.
It theoretically is possible that some people were expecting and
relying on that the attribute set as the "diff.commit" color, which
is used to draw these opening parenthesis and inter-item comma, is
inherited by the drawing of branch names, but it is not how the
coloring works everywhere else.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-04 19:07:12 +00:00
|
|
|
${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_stash}refs/stash${c_reset}${c_commit})${c_reset}\
|
2020-11-18 23:44:27 +00:00
|
|
|
On main: Changes to A.t
|
log --decorate: do not leak "commit" color into the next item
In "git log --decorate", you would see the commit header like this:
commit ... (HEAD, jc/decorate-leaky-separator-color)
where "commit ... (" is painted in color.diff.commit, "HEAD" in
color.decorate.head, ", " in color.diff.commit, the branch name in
color.decorate.branch and then closing ")" in color.diff.commit.
If you wanted to paint the HEAD and local branch name in the same
color as the body text (perhaps because cyan and green are too faint
on a black-on-white terminal to be readable), you would not want to
have to say
[color "decorate"]
head = black
branch = black
because that you would not be able to reuse same configuration on a
white-on-black terminal. You would naively expect
[color "decorate"]
head = normal
branch = normal
to work, but unfortunately it does not. It paints the string "HEAD"
and the branch name in the same color as the opening parenthesis or
comma between the decoration elements. This is because the code
forgets to reset the color after printing the "prefix" in its own
color.
It theoretically is possible that some people were expecting and
relying on that the attribute set as the "diff.commit" color, which
is used to draw these opening parenthesis and inter-item comma, is
inherited by the drawing of branch names, but it is not how the
coloring works everywhere else.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-04 19:07:12 +00:00
|
|
|
${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_tag}tag: A${c_reset}${c_commit})${c_reset} A
|
2010-06-29 07:47:08 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
# We want log to show all, but the second parent to refs/stash is irrelevant
|
|
|
|
# to this test since it does not contain any decoration, hence --first-parent
|
|
|
|
test_expect_success 'Commit Decorations Colored Correctly' '
|
|
|
|
git log --first-parent --abbrev=10 --all --decorate --oneline --color=always |
|
2017-07-13 14:58:41 +00:00
|
|
|
sed "s/[0-9a-f]\{10,10\}/COMMIT_ID/" |
|
|
|
|
test_decode_color >out &&
|
2010-06-29 07:47:08 +00:00
|
|
|
test_cmp expected out
|
|
|
|
'
|
|
|
|
|
|
|
|
test_done
|