git/t/t4214-log-graph-octopus.sh

352 lines
10 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='git log --graph of skewed left octopus merge.'
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
TEST_PASSES_SANITIZE_LEAK=true
. ./test-lib.sh
. "$TEST_DIRECTORY"/lib-log-graph.sh
test_cmp_graph () {
cat >expect &&
lib_test_cmp_graph --color=never --date-order --format=%s "$@"
}
test_cmp_colored_graph () {
lib_test_cmp_colored_graph --date-order --format=%s "$@"
}
test_expect_success 'set up merge history' '
test_commit initial &&
for i in 1 2 3 4 ; do
git checkout main -b $i || return $?
# Make tag name different from branch name, to avoid
# ambiguity error when calling checkout.
test_commit $i $i $i tag$i || return $?
done &&
git checkout 1 -b merge &&
test_merge octopus-merge 1 2 3 4 &&
test_commit after-merge &&
git checkout 1 -b L &&
test_commit left &&
git checkout 4 -b crossover &&
test_commit after-4 &&
git checkout initial -b more-L &&
test_commit after-initial
'
test_expect_success 'log --graph with tricky octopus merge, no color' '
test_cmp_graph left octopus-merge <<-\EOF
* left
| *-. octopus-merge
|/|\ \
| | | * 4
| | * | 3
| | |/
| * / 2
| |/
* / 1
|/
* initial
EOF
'
test_expect_success 'log --graph with tricky octopus merge with colors' '
test_config log.graphColors red,green,yellow,blue,magenta,cyan &&
cat >expect.colors <<-\EOF &&
* left
<RED>|<RESET> *<MAGENTA>-<RESET><MAGENTA>.<RESET> octopus-merge
<RED>|<RESET><RED>/<RESET><YELLOW>|<RESET><BLUE>\<RESET> <MAGENTA>\<RESET>
<RED>|<RESET> <YELLOW>|<RESET> <BLUE>|<RESET> * 4
<RED>|<RESET> <YELLOW>|<RESET> * <MAGENTA>|<RESET> 3
<RED>|<RESET> <YELLOW>|<RESET> <MAGENTA>|<RESET><MAGENTA>/<RESET>
<RED>|<RESET> * <MAGENTA>/<RESET> 2
<RED>|<RESET> <MAGENTA>|<RESET><MAGENTA>/<RESET>
* <MAGENTA>/<RESET> 1
<MAGENTA>|<RESET><MAGENTA>/<RESET>
* initial
EOF
test_cmp_colored_graph left octopus-merge
'
# Repeat the previous two tests with "normal" octopus merge (i.e.,
# without the first parent skewing to the "left" branch column).
test_expect_success 'log --graph with normal octopus merge, no color' '
test_cmp_graph octopus-merge <<-\EOF
*---. octopus-merge
|\ \ \
| | | * 4
| | * | 3
| | |/
| * / 2
| |/
* / 1
|/
* initial
EOF
'
test_expect_success 'log --graph with normal octopus merge with colors' '
cat >expect.colors <<-\EOF &&
*<YELLOW>-<RESET><YELLOW>-<RESET><BLUE>-<RESET><BLUE>.<RESET> octopus-merge
<RED>|<RESET><GREEN>\<RESET> <YELLOW>\<RESET> <BLUE>\<RESET>
<RED>|<RESET> <GREEN>|<RESET> <YELLOW>|<RESET> * 4
<RED>|<RESET> <GREEN>|<RESET> * <BLUE>|<RESET> 3
<RED>|<RESET> <GREEN>|<RESET> <BLUE>|<RESET><BLUE>/<RESET>
<RED>|<RESET> * <BLUE>/<RESET> 2
<RED>|<RESET> <BLUE>|<RESET><BLUE>/<RESET>
* <BLUE>/<RESET> 1
<BLUE>|<RESET><BLUE>/<RESET>
* initial
EOF
test_config log.graphColors red,green,yellow,blue,magenta,cyan &&
test_cmp_colored_graph octopus-merge
'
test_expect_success 'log --graph with normal octopus merge and child, no color' '
test_cmp_graph after-merge <<-\EOF
* after-merge
*---. octopus-merge
|\ \ \
| | | * 4
| | * | 3
| | |/
| * / 2
| |/
* / 1
|/
* initial
EOF
'
graph: fix coloring of octopus dashes In 04005834ed ("log: fix coloring of certain octopus merge shapes", 2018-09-01) there is a fix for the coloring of dashes following an octopus merge. It makes a distinction between the case where all parents introduce a new column, versus the case where the first parent collapses into an existing column: | *-. | *-. | |\ \ | |\ \ | | | | |/ / / The latter case means that the columns for the merge parents begin one place to the left in the `new_columns` array compared to the former case. However, the implementation only works if the commit's parents are kept in order as they map onto the visual columns, as we get the colors by iterating over `new_columns` as we print the dashes. In general, the commit's parents can arbitrarily merge with existing columns, and change their ordering in the process. For example, in the following diagram, the number of each column indicates which commit parent appears in each column. | | *---. | | |\ \ \ | | |/ / / | |/| | / | |_|_|/ |/| | | 3 1 0 2 If the columns are colored (red, green, yellow, blue), then the dashes will currently be colored yellow and blue, whereas they should be blue and red. To fix this, we need to look up each column in the `mapping` array, which before the `GRAPH_COLLAPSING` state indicates which logical column is displayed in each visual column. This implementation is simpler as it doesn't have any edge cases, and it also handles how left-skewed first parents are now displayed: | *-. |/|\ \ | | | | 0 1 2 3 The color of the first dashes is always the color found in `mapping` two columns to the right of the commit symbol. Because commits are displayed after all edges have been collapsed together and the visual columns match the logical ones, we can find the visual offset of the commit symbol using `commit_index`. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:59 +00:00
test_expect_success 'log --graph with normal octopus and child merge with colors' '
cat >expect.colors <<-\EOF &&
* after-merge
*<BLUE>-<RESET><BLUE>-<RESET><MAGENTA>-<RESET><MAGENTA>.<RESET> octopus-merge
<GREEN>|<RESET><YELLOW>\<RESET> <BLUE>\<RESET> <MAGENTA>\<RESET>
<GREEN>|<RESET> <YELLOW>|<RESET> <BLUE>|<RESET> * 4
<GREEN>|<RESET> <YELLOW>|<RESET> * <MAGENTA>|<RESET> 3
<GREEN>|<RESET> <YELLOW>|<RESET> <MAGENTA>|<RESET><MAGENTA>/<RESET>
<GREEN>|<RESET> * <MAGENTA>/<RESET> 2
<GREEN>|<RESET> <MAGENTA>|<RESET><MAGENTA>/<RESET>
* <MAGENTA>/<RESET> 1
<MAGENTA>|<RESET><MAGENTA>/<RESET>
* initial
EOF
test_config log.graphColors red,green,yellow,blue,magenta,cyan &&
test_cmp_colored_graph after-merge
'
test_expect_success 'log --graph with tricky octopus merge and its child, no color' '
test_cmp_graph left after-merge <<-\EOF
* left
| * after-merge
| *-. octopus-merge
|/|\ \
| | | * 4
| | * | 3
| | |/
| * / 2
| |/
* / 1
|/
* initial
EOF
'
graph: fix coloring of octopus dashes In 04005834ed ("log: fix coloring of certain octopus merge shapes", 2018-09-01) there is a fix for the coloring of dashes following an octopus merge. It makes a distinction between the case where all parents introduce a new column, versus the case where the first parent collapses into an existing column: | *-. | *-. | |\ \ | |\ \ | | | | |/ / / The latter case means that the columns for the merge parents begin one place to the left in the `new_columns` array compared to the former case. However, the implementation only works if the commit's parents are kept in order as they map onto the visual columns, as we get the colors by iterating over `new_columns` as we print the dashes. In general, the commit's parents can arbitrarily merge with existing columns, and change their ordering in the process. For example, in the following diagram, the number of each column indicates which commit parent appears in each column. | | *---. | | |\ \ \ | | |/ / / | |/| | / | |_|_|/ |/| | | 3 1 0 2 If the columns are colored (red, green, yellow, blue), then the dashes will currently be colored yellow and blue, whereas they should be blue and red. To fix this, we need to look up each column in the `mapping` array, which before the `GRAPH_COLLAPSING` state indicates which logical column is displayed in each visual column. This implementation is simpler as it doesn't have any edge cases, and it also handles how left-skewed first parents are now displayed: | *-. |/|\ \ | | | | 0 1 2 3 The color of the first dashes is always the color found in `mapping` two columns to the right of the commit symbol. Because commits are displayed after all edges have been collapsed together and the visual columns match the logical ones, we can find the visual offset of the commit symbol using `commit_index`. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:59 +00:00
test_expect_success 'log --graph with tricky octopus merge and its child with colors' '
test_config log.graphColors red,green,yellow,blue,magenta,cyan &&
cat >expect.colors <<-\EOF &&
* left
<RED>|<RESET> * after-merge
<RED>|<RESET> *<CYAN>-<RESET><CYAN>.<RESET> octopus-merge
<RED>|<RESET><RED>/<RESET><BLUE>|<RESET><MAGENTA>\<RESET> <CYAN>\<RESET>
<RED>|<RESET> <BLUE>|<RESET> <MAGENTA>|<RESET> * 4
<RED>|<RESET> <BLUE>|<RESET> * <CYAN>|<RESET> 3
<RED>|<RESET> <BLUE>|<RESET> <CYAN>|<RESET><CYAN>/<RESET>
<RED>|<RESET> * <CYAN>/<RESET> 2
<RED>|<RESET> <CYAN>|<RESET><CYAN>/<RESET>
* <CYAN>/<RESET> 1
<CYAN>|<RESET><CYAN>/<RESET>
* initial
EOF
test_cmp_colored_graph left after-merge
'
test_expect_success 'log --graph with crossover in octopus merge, no color' '
test_cmp_graph after-4 octopus-merge <<-\EOF
* after-4
| *---. octopus-merge
| |\ \ \
| |_|_|/
|/| | |
* | | | 4
| | | * 3
| |_|/
|/| |
| | * 2
| |/
|/|
| * 1
|/
* initial
EOF
'
graph: fix coloring of octopus dashes In 04005834ed ("log: fix coloring of certain octopus merge shapes", 2018-09-01) there is a fix for the coloring of dashes following an octopus merge. It makes a distinction between the case where all parents introduce a new column, versus the case where the first parent collapses into an existing column: | *-. | *-. | |\ \ | |\ \ | | | | |/ / / The latter case means that the columns for the merge parents begin one place to the left in the `new_columns` array compared to the former case. However, the implementation only works if the commit's parents are kept in order as they map onto the visual columns, as we get the colors by iterating over `new_columns` as we print the dashes. In general, the commit's parents can arbitrarily merge with existing columns, and change their ordering in the process. For example, in the following diagram, the number of each column indicates which commit parent appears in each column. | | *---. | | |\ \ \ | | |/ / / | |/| | / | |_|_|/ |/| | | 3 1 0 2 If the columns are colored (red, green, yellow, blue), then the dashes will currently be colored yellow and blue, whereas they should be blue and red. To fix this, we need to look up each column in the `mapping` array, which before the `GRAPH_COLLAPSING` state indicates which logical column is displayed in each visual column. This implementation is simpler as it doesn't have any edge cases, and it also handles how left-skewed first parents are now displayed: | *-. |/|\ \ | | | | 0 1 2 3 The color of the first dashes is always the color found in `mapping` two columns to the right of the commit symbol. Because commits are displayed after all edges have been collapsed together and the visual columns match the logical ones, we can find the visual offset of the commit symbol using `commit_index`. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:59 +00:00
test_expect_success 'log --graph with crossover in octopus merge with colors' '
test_config log.graphColors red,green,yellow,blue,magenta,cyan &&
cat >expect.colors <<-\EOF &&
* after-4
<RED>|<RESET> *<BLUE>-<RESET><BLUE>-<RESET><RED>-<RESET><RED>.<RESET> octopus-merge
<RED>|<RESET> <GREEN>|<RESET><YELLOW>\<RESET> <BLUE>\<RESET> <RED>\<RESET>
<RED>|<RESET> <GREEN>|<RESET><RED>_<RESET><YELLOW>|<RESET><RED>_<RESET><BLUE>|<RESET><RED>/<RESET>
<RED>|<RESET><RED>/<RESET><GREEN>|<RESET> <YELLOW>|<RESET> <BLUE>|<RESET>
* <GREEN>|<RESET> <YELLOW>|<RESET> <BLUE>|<RESET> 4
<MAGENTA>|<RESET> <GREEN>|<RESET> <YELLOW>|<RESET> * 3
<MAGENTA>|<RESET> <GREEN>|<RESET><MAGENTA>_<RESET><YELLOW>|<RESET><MAGENTA>/<RESET>
<MAGENTA>|<RESET><MAGENTA>/<RESET><GREEN>|<RESET> <YELLOW>|<RESET>
<MAGENTA>|<RESET> <GREEN>|<RESET> * 2
<MAGENTA>|<RESET> <GREEN>|<RESET><MAGENTA>/<RESET>
<MAGENTA>|<RESET><MAGENTA>/<RESET><GREEN>|<RESET>
<MAGENTA>|<RESET> * 1
<MAGENTA>|<RESET><MAGENTA>/<RESET>
* initial
EOF
test_cmp_colored_graph after-4 octopus-merge
'
test_expect_success 'log --graph with crossover in octopus merge and its child, no color' '
test_cmp_graph after-4 after-merge <<-\EOF
* after-4
| * after-merge
| *---. octopus-merge
| |\ \ \
| |_|_|/
|/| | |
* | | | 4
| | | * 3
| |_|/
|/| |
| | * 2
| |/
|/|
| * 1
|/
* initial
EOF
'
graph: fix coloring of octopus dashes In 04005834ed ("log: fix coloring of certain octopus merge shapes", 2018-09-01) there is a fix for the coloring of dashes following an octopus merge. It makes a distinction between the case where all parents introduce a new column, versus the case where the first parent collapses into an existing column: | *-. | *-. | |\ \ | |\ \ | | | | |/ / / The latter case means that the columns for the merge parents begin one place to the left in the `new_columns` array compared to the former case. However, the implementation only works if the commit's parents are kept in order as they map onto the visual columns, as we get the colors by iterating over `new_columns` as we print the dashes. In general, the commit's parents can arbitrarily merge with existing columns, and change their ordering in the process. For example, in the following diagram, the number of each column indicates which commit parent appears in each column. | | *---. | | |\ \ \ | | |/ / / | |/| | / | |_|_|/ |/| | | 3 1 0 2 If the columns are colored (red, green, yellow, blue), then the dashes will currently be colored yellow and blue, whereas they should be blue and red. To fix this, we need to look up each column in the `mapping` array, which before the `GRAPH_COLLAPSING` state indicates which logical column is displayed in each visual column. This implementation is simpler as it doesn't have any edge cases, and it also handles how left-skewed first parents are now displayed: | *-. |/|\ \ | | | | 0 1 2 3 The color of the first dashes is always the color found in `mapping` two columns to the right of the commit symbol. Because commits are displayed after all edges have been collapsed together and the visual columns match the logical ones, we can find the visual offset of the commit symbol using `commit_index`. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:59 +00:00
test_expect_success 'log --graph with crossover in octopus merge and its child with colors' '
test_config log.graphColors red,green,yellow,blue,magenta,cyan &&
cat >expect.colors <<-\EOF &&
* after-4
<RED>|<RESET> * after-merge
<RED>|<RESET> *<MAGENTA>-<RESET><MAGENTA>-<RESET><RED>-<RESET><RED>.<RESET> octopus-merge
<RED>|<RESET> <YELLOW>|<RESET><BLUE>\<RESET> <MAGENTA>\<RESET> <RED>\<RESET>
<RED>|<RESET> <YELLOW>|<RESET><RED>_<RESET><BLUE>|<RESET><RED>_<RESET><MAGENTA>|<RESET><RED>/<RESET>
<RED>|<RESET><RED>/<RESET><YELLOW>|<RESET> <BLUE>|<RESET> <MAGENTA>|<RESET>
* <YELLOW>|<RESET> <BLUE>|<RESET> <MAGENTA>|<RESET> 4
<CYAN>|<RESET> <YELLOW>|<RESET> <BLUE>|<RESET> * 3
<CYAN>|<RESET> <YELLOW>|<RESET><CYAN>_<RESET><BLUE>|<RESET><CYAN>/<RESET>
<CYAN>|<RESET><CYAN>/<RESET><YELLOW>|<RESET> <BLUE>|<RESET>
<CYAN>|<RESET> <YELLOW>|<RESET> * 2
<CYAN>|<RESET> <YELLOW>|<RESET><CYAN>/<RESET>
<CYAN>|<RESET><CYAN>/<RESET><YELLOW>|<RESET>
<CYAN>|<RESET> * 1
<CYAN>|<RESET><CYAN>/<RESET>
* initial
EOF
test_cmp_colored_graph after-4 after-merge
'
test_expect_success 'log --graph with unrelated commit and octopus tip, no color' '
test_cmp_graph after-initial octopus-merge <<-\EOF
* after-initial
| *---. octopus-merge
| |\ \ \
| | | | * 4
| |_|_|/
|/| | |
| | | * 3
| |_|/
|/| |
| | * 2
| |/
|/|
| * 1
|/
* initial
EOF
'
test_expect_success 'log --graph with unrelated commit and octopus tip with colors' '
test_config log.graphColors red,green,yellow,blue,magenta,cyan &&
cat >expect.colors <<-\EOF &&
* after-initial
<RED>|<RESET> *<BLUE>-<RESET><BLUE>-<RESET><MAGENTA>-<RESET><MAGENTA>.<RESET> octopus-merge
<RED>|<RESET> <GREEN>|<RESET><YELLOW>\<RESET> <BLUE>\<RESET> <MAGENTA>\<RESET>
<RED>|<RESET> <GREEN>|<RESET> <YELLOW>|<RESET> <BLUE>|<RESET> * 4
<RED>|<RESET> <GREEN>|<RESET><RED>_<RESET><YELLOW>|<RESET><RED>_<RESET><BLUE>|<RESET><RED>/<RESET>
<RED>|<RESET><RED>/<RESET><GREEN>|<RESET> <YELLOW>|<RESET> <BLUE>|<RESET>
<RED>|<RESET> <GREEN>|<RESET> <YELLOW>|<RESET> * 3
<RED>|<RESET> <GREEN>|<RESET><RED>_<RESET><YELLOW>|<RESET><RED>/<RESET>
<RED>|<RESET><RED>/<RESET><GREEN>|<RESET> <YELLOW>|<RESET>
<RED>|<RESET> <GREEN>|<RESET> * 2
<RED>|<RESET> <GREEN>|<RESET><RED>/<RESET>
<RED>|<RESET><RED>/<RESET><GREEN>|<RESET>
<RED>|<RESET> * 1
<RED>|<RESET><RED>/<RESET>
* initial
EOF
test_cmp_colored_graph after-initial octopus-merge
'
test_expect_success 'log --graph with unrelated commit and octopus child, no color' '
test_cmp_graph after-initial after-merge <<-\EOF
* after-initial
| * after-merge
| *---. octopus-merge
| |\ \ \
| | | | * 4
| |_|_|/
|/| | |
| | | * 3
| |_|/
|/| |
| | * 2
| |/
|/|
| * 1
|/
* initial
EOF
'
graph: fix coloring of octopus dashes In 04005834ed ("log: fix coloring of certain octopus merge shapes", 2018-09-01) there is a fix for the coloring of dashes following an octopus merge. It makes a distinction between the case where all parents introduce a new column, versus the case where the first parent collapses into an existing column: | *-. | *-. | |\ \ | |\ \ | | | | |/ / / The latter case means that the columns for the merge parents begin one place to the left in the `new_columns` array compared to the former case. However, the implementation only works if the commit's parents are kept in order as they map onto the visual columns, as we get the colors by iterating over `new_columns` as we print the dashes. In general, the commit's parents can arbitrarily merge with existing columns, and change their ordering in the process. For example, in the following diagram, the number of each column indicates which commit parent appears in each column. | | *---. | | |\ \ \ | | |/ / / | |/| | / | |_|_|/ |/| | | 3 1 0 2 If the columns are colored (red, green, yellow, blue), then the dashes will currently be colored yellow and blue, whereas they should be blue and red. To fix this, we need to look up each column in the `mapping` array, which before the `GRAPH_COLLAPSING` state indicates which logical column is displayed in each visual column. This implementation is simpler as it doesn't have any edge cases, and it also handles how left-skewed first parents are now displayed: | *-. |/|\ \ | | | | 0 1 2 3 The color of the first dashes is always the color found in `mapping` two columns to the right of the commit symbol. Because commits are displayed after all edges have been collapsed together and the visual columns match the logical ones, we can find the visual offset of the commit symbol using `commit_index`. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:59 +00:00
test_expect_success 'log --graph with unrelated commit and octopus child with colors' '
test_config log.graphColors red,green,yellow,blue,magenta,cyan &&
cat >expect.colors <<-\EOF &&
* after-initial
<RED>|<RESET> * after-merge
<RED>|<RESET> *<MAGENTA>-<RESET><MAGENTA>-<RESET><CYAN>-<RESET><CYAN>.<RESET> octopus-merge
<RED>|<RESET> <YELLOW>|<RESET><BLUE>\<RESET> <MAGENTA>\<RESET> <CYAN>\<RESET>
<RED>|<RESET> <YELLOW>|<RESET> <BLUE>|<RESET> <MAGENTA>|<RESET> * 4
<RED>|<RESET> <YELLOW>|<RESET><RED>_<RESET><BLUE>|<RESET><RED>_<RESET><MAGENTA>|<RESET><RED>/<RESET>
<RED>|<RESET><RED>/<RESET><YELLOW>|<RESET> <BLUE>|<RESET> <MAGENTA>|<RESET>
<RED>|<RESET> <YELLOW>|<RESET> <BLUE>|<RESET> * 3
<RED>|<RESET> <YELLOW>|<RESET><RED>_<RESET><BLUE>|<RESET><RED>/<RESET>
<RED>|<RESET><RED>/<RESET><YELLOW>|<RESET> <BLUE>|<RESET>
<RED>|<RESET> <YELLOW>|<RESET> * 2
<RED>|<RESET> <YELLOW>|<RESET><RED>/<RESET>
<RED>|<RESET><RED>/<RESET><YELLOW>|<RESET>
<RED>|<RESET> * 1
<RED>|<RESET><RED>/<RESET>
* initial
EOF
test_cmp_colored_graph after-initial after-merge
'
test_done