development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-11-05 18:59:29 +00:00
Code Issues Projects Releases Packages Wiki Activity
git/t/t4215-log-skewed-merges.sh

375 lines
7.6 KiB
Bash
Raw Normal View History

graph: example of graph output that can be simplified The commits following this one introduce a series of improvements to the layout of graphs, tidying up a few edge cases, namely: - merge whose first parent fuses with an existing column to the left - merge whose last parent fuses with its immediate neighbor on the right - edges that collapse to the left above and below a commit line This test case exemplifies these cases and provides a motivating example of the kind of history I'm aiming to clear up. The first parent of merge E is the same as the parent of H, so those edges fuse together. * H | | *-. E | |\ \ |/ / / | * B We can "skew" the display of this merge so that it doesn't introduce additional columns that immediately collapse: * H | | * E |/|\ | * B The last parent of E is D, the same as the parent of F which is the edge to the right of the merge. * F | \ *-. \ E |\ \ \ / / / / | / |/ * D The two edges leading to D could be fused sooner: rather than expanding the F edge around the merge and then letting the edges collapse, the F edge could fuse with the E edge in the post-merge line: * F | \ *-. | E |\ \| / / / | * D If this is combined with the "skew" effect above, we get a much cleaner graph display for these edges: * F | * | E /|\| | * D Finally, the edge leading from C to A appears jagged as it passes through the commit line for B: | * | C | |/ * | B |/ * A This can be smoothed out so that such edges are easier to read: | * | C | |/ * / B |/ * A Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:53 +00:00
#!/bin/sh
test_description='git log --graph of skewed merges'
merge: free result of repo_get_merge_bases() We call repo_get_merge_bases(), which allocates a commit_list, but never free the result, causing a leak. The obvious solution is to free it, but we need to look at the contents of the first item to decide whether to leave the loop. One option is to free it in both code paths. But since the commit that the list points to is longer-lived than the list itself, we can just dereference it immediately, free the list, and then continue with the existing logic. This is about the same amount of code, but keeps the list management all in one place. This lets us mark a number of merge-related test scripts as leak-free. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-03 20:27:24 +00:00
TEST_PASSES_SANITIZE_LEAK=true
graph: example of graph output that can be simplified The commits following this one introduce a series of improvements to the layout of graphs, tidying up a few edge cases, namely: - merge whose first parent fuses with an existing column to the left - merge whose last parent fuses with its immediate neighbor on the right - edges that collapse to the left above and below a commit line This test case exemplifies these cases and provides a motivating example of the kind of history I'm aiming to clear up. The first parent of merge E is the same as the parent of H, so those edges fuse together. * H | | *-. E | |\ \ |/ / / | * B We can "skew" the display of this merge so that it doesn't introduce additional columns that immediately collapse: * H | | * E |/|\ | * B The last parent of E is D, the same as the parent of F which is the edge to the right of the merge. * F | \ *-. \ E |\ \ \ / / / / | / |/ * D The two edges leading to D could be fused sooner: rather than expanding the F edge around the merge and then letting the edges collapse, the F edge could fuse with the E edge in the post-merge line: * F | \ *-. | E |\ \| / / / | * D If this is combined with the "skew" effect above, we get a much cleaner graph display for these edges: * F | * | E /|\| | * D Finally, the edge leading from C to A appears jagged as it passes through the commit line for B: | * | C | |/ * | B |/ * A This can be smoothed out so that such edges are easier to read: | * | C | |/ * / B |/ * A Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:53 +00:00
. ./test-lib.sh
lib-log-graph: consolidate test_cmp_graph logic Log graph comparision logic is duplicated many times in: - t3430-rebase-merges.sh - t4202-log.sh - t4214-log-graph-octopus.sh - t4215-log-skewed-merges.sh Consolidate the core of the comparision and sanitization logic in lib-log-graph, and use it to replace the existing tests. While at it, lose the singular/plural transition magic from the sanitize_output helper, which was necessary around 7f814632 ("Use correct grammar in diffstat summary line", 2012-02-01), that has long outlived its usefulness. Signed-off-by: Abhishek Kumar <abhishekkumar8222@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-24 13:38:13 +00:00
. "$TEST_DIRECTORY"/lib-log-graph.sh
graph: example of graph output that can be simplified The commits following this one introduce a series of improvements to the layout of graphs, tidying up a few edge cases, namely: - merge whose first parent fuses with an existing column to the left - merge whose last parent fuses with its immediate neighbor on the right - edges that collapse to the left above and below a commit line This test case exemplifies these cases and provides a motivating example of the kind of history I'm aiming to clear up. The first parent of merge E is the same as the parent of H, so those edges fuse together. * H | | *-. E | |\ \ |/ / / | * B We can "skew" the display of this merge so that it doesn't introduce additional columns that immediately collapse: * H | | * E |/|\ | * B The last parent of E is D, the same as the parent of F which is the edge to the right of the merge. * F | \ *-. \ E |\ \ \ / / / / | / |/ * D The two edges leading to D could be fused sooner: rather than expanding the F edge around the merge and then letting the edges collapse, the F edge could fuse with the E edge in the post-merge line: * F | \ *-. | E |\ \| / / / | * D If this is combined with the "skew" effect above, we get a much cleaner graph display for these edges: * F | * | E /|\| | * D Finally, the edge leading from C to A appears jagged as it passes through the commit line for B: | * | C | |/ * | B |/ * A This can be smoothed out so that such edges are easier to read: | * | C | |/ * / B |/ * A Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:53 +00:00
t4215: use helper function to check output When git commands are placed in the upstream of a pipe, their return codes are lost. In this particular case, it is especially bad since we are testing the intricacies of `git log --graph` behavior and if we hit an unexpected failure or segfault, we want to know this. Extract the common output checking logic into check_graph() where we redirect the output of git commands upstream of pipe into a file and have sed read from that file so that git failures are detected. This patch is best viewed with `--color-moved`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-12 18:56:22 +00:00
check_graph () {
cat >expect &&
lib-log-graph: consolidate test_cmp_graph logic Log graph comparision logic is duplicated many times in: - t3430-rebase-merges.sh - t4202-log.sh - t4214-log-graph-octopus.sh - t4215-log-skewed-merges.sh Consolidate the core of the comparision and sanitization logic in lib-log-graph, and use it to replace the existing tests. While at it, lose the singular/plural transition magic from the sanitize_output helper, which was necessary around 7f814632 ("Use correct grammar in diffstat summary line", 2012-02-01), that has long outlived its usefulness. Signed-off-by: Abhishek Kumar <abhishekkumar8222@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-24 13:38:13 +00:00
lib_test_cmp_graph --format=%s "$@"
t4215: use helper function to check output When git commands are placed in the upstream of a pipe, their return codes are lost. In this particular case, it is especially bad since we are testing the intricacies of `git log --graph` behavior and if we hit an unexpected failure or segfault, we want to know this. Extract the common output checking logic into check_graph() where we redirect the output of git commands upstream of pipe into a file and have sed read from that file so that git failures are detected. This patch is best viewed with `--color-moved`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-12 18:56:22 +00:00
}
graph: example of graph output that can be simplified The commits following this one introduce a series of improvements to the layout of graphs, tidying up a few edge cases, namely: - merge whose first parent fuses with an existing column to the left - merge whose last parent fuses with its immediate neighbor on the right - edges that collapse to the left above and below a commit line This test case exemplifies these cases and provides a motivating example of the kind of history I'm aiming to clear up. The first parent of merge E is the same as the parent of H, so those edges fuse together. * H | | *-. E | |\ \ |/ / / | * B We can "skew" the display of this merge so that it doesn't introduce additional columns that immediately collapse: * H | | * E |/|\ | * B The last parent of E is D, the same as the parent of F which is the edge to the right of the merge. * F | \ *-. \ E |\ \ \ / / / / | / |/ * D The two edges leading to D could be fused sooner: rather than expanding the F edge around the merge and then letting the edges collapse, the F edge could fuse with the E edge in the post-merge line: * F | \ *-. | E |\ \| / / / | * D If this is combined with the "skew" effect above, we get a much cleaner graph display for these edges: * F | * | E /|\| | * D Finally, the edge leading from C to A appears jagged as it passes through the commit line for B: | * | C | |/ * | B |/ * A This can be smoothed out so that such edges are easier to read: | * | C | |/ * / B |/ * A Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:53 +00:00
test_expect_success 'log --graph with merge fusing with its left and right neighbors' '
t4215: use helper function to check output When git commands are placed in the upstream of a pipe, their return codes are lost. In this particular case, it is especially bad since we are testing the intricacies of `git log --graph` behavior and if we hit an unexpected failure or segfault, we want to know this. Extract the common output checking logic into check_graph() where we redirect the output of git commands upstream of pipe into a file and have sed read from that file so that git failures are detected. This patch is best viewed with `--color-moved`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-12 18:56:22 +00:00
git checkout --orphan _p &&
test_commit A &&
test_commit B &&
git checkout -b _q @^ && test_commit C &&
git checkout -b _r @^ && test_commit D &&
git checkout _p && git merge --no-ff _q _r -m E &&
git checkout _r && test_commit F &&
git checkout _p && git merge --no-ff _r -m G &&
git checkout @^^ && git merge --no-ff _p -m H &&
check_graph <<-\EOF
graph: example of graph output that can be simplified The commits following this one introduce a series of improvements to the layout of graphs, tidying up a few edge cases, namely: - merge whose first parent fuses with an existing column to the left - merge whose last parent fuses with its immediate neighbor on the right - edges that collapse to the left above and below a commit line This test case exemplifies these cases and provides a motivating example of the kind of history I'm aiming to clear up. The first parent of merge E is the same as the parent of H, so those edges fuse together. * H | | *-. E | |\ \ |/ / / | * B We can "skew" the display of this merge so that it doesn't introduce additional columns that immediately collapse: * H | | * E |/|\ | * B The last parent of E is D, the same as the parent of F which is the edge to the right of the merge. * F | \ *-. \ E |\ \ \ / / / / | / |/ * D The two edges leading to D could be fused sooner: rather than expanding the F edge around the merge and then letting the edges collapse, the F edge could fuse with the E edge in the post-merge line: * F | \ *-. | E |\ \| / / / | * D If this is combined with the "skew" effect above, we get a much cleaner graph display for these edges: * F | * | E /|\| | * D Finally, the edge leading from C to A appears jagged as it passes through the commit line for B: | * | C | |/ * | B |/ * A This can be smoothed out so that such edges are easier to read: | * | C | |/ * / B |/ * A Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:53 +00:00
* H
|\
| * G
| |\
| | * F
graph: flatten edges that fuse with their right neighbor When a merge commit is printed and its final parent is the same commit that occupies the column to the right of the merge, this results in a kink in the displayed edges: * | |\ \ | |/ | * Graphs containing these shapes can be hard to read, as the expansion to the right followed immediately by collapsing back to the left creates a lot of zig-zagging edges, especially when many columns are present. We can improve this by eliminating the zig-zag and having the merge's final parent edge fuse immediately with its neighbor: * | |\| | * This reduces the horizontal width for the current commit by 2, and requires one less row, making the graph display more compact. Taken in combination with other graph-smoothing enhancements, it greatly compresses the space needed to display certain histories: * |\ | * * | |\ |\ | | * | * | | | | |\ | | \ | | * | *-. \ | * | | |\ \ \ => |/|\| |/ / / / | | * | | | / | * | | | |/ | |/ | | * * / | * | |/ | |/ * * | |/ * One of the test cases here cannot be correctly rendered in Git v2.23.0; it produces this output following commit E: | | *-. \ 5_E | | |\ \ \ | |/ / / / | | | / _ | |_|/ |/| | The new implementation makes sure that the rightmost edge in this history is not left dangling as above. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:58 +00:00
| * | E
|/|\|
graph: example of graph output that can be simplified The commits following this one introduce a series of improvements to the layout of graphs, tidying up a few edge cases, namely: - merge whose first parent fuses with an existing column to the left - merge whose last parent fuses with its immediate neighbor on the right - edges that collapse to the left above and below a commit line This test case exemplifies these cases and provides a motivating example of the kind of history I'm aiming to clear up. The first parent of merge E is the same as the parent of H, so those edges fuse together. * H | | *-. E | |\ \ |/ / / | * B We can "skew" the display of this merge so that it doesn't introduce additional columns that immediately collapse: * H | | * E |/|\ | * B The last parent of E is D, the same as the parent of F which is the edge to the right of the merge. * F | \ *-. \ E |\ \ \ / / / / | / |/ * D The two edges leading to D could be fused sooner: rather than expanding the F edge around the merge and then letting the edges collapse, the F edge could fuse with the E edge in the post-merge line: * F | \ *-. | E |\ \| / / / | * D If this is combined with the "skew" effect above, we get a much cleaner graph display for these edges: * F | * | E /|\| | * D Finally, the edge leading from C to A appears jagged as it passes through the commit line for B: | * | C | |/ * | B |/ * A This can be smoothed out so that such edges are easier to read: | * | C | |/ * / B |/ * A Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:53 +00:00
| | * D
| * | C
| |/
graph: smooth appearance of collapsing edges on commit lines When a graph contains edges that are in the process of collapsing to the left, but those edges cross a commit line, the effect is that the edges have a jagged appearance: * |\ | * | \ *-. \ |\ \ \ | | * | | * | | | |/ / * | | |/ / * | |/ * We already takes steps to smooth edges like this when they're expanding; when an edge appears to the right of a merge commit marker on a GRAPH_COMMIT line immediately following a GRAPH_POST_MERGE line, we render it as a `\`: * \ |\ \ | * \ | |\ \ We can make a similar improvement to collapsing edges, making them easier to follow and giving the overall graph a feeling of increased symmetry: * |\ | * | \ *-. \ |\ \ \ | | * | | * | | | |/ / * / / |/ / * / |/ * To do this, we introduce a new special case for edges on GRAPH_COMMIT lines that immediately follow a GRAPH_COLLAPSING line. By retaining a copy of the `mapping` array used to render the GRAPH_COLLAPSING line in the `old_mapping` array, we can determine that an edge is collapsing through the GRAPH_COMMIT line and should be smoothed. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:57 +00:00
* / B
graph: example of graph output that can be simplified The commits following this one introduce a series of improvements to the layout of graphs, tidying up a few edge cases, namely: - merge whose first parent fuses with an existing column to the left - merge whose last parent fuses with its immediate neighbor on the right - edges that collapse to the left above and below a commit line This test case exemplifies these cases and provides a motivating example of the kind of history I'm aiming to clear up. The first parent of merge E is the same as the parent of H, so those edges fuse together. * H | | *-. E | |\ \ |/ / / | * B We can "skew" the display of this merge so that it doesn't introduce additional columns that immediately collapse: * H | | * E |/|\ | * B The last parent of E is D, the same as the parent of F which is the edge to the right of the merge. * F | \ *-. \ E |\ \ \ / / / / | / |/ * D The two edges leading to D could be fused sooner: rather than expanding the F edge around the merge and then letting the edges collapse, the F edge could fuse with the E edge in the post-merge line: * F | \ *-. | E |\ \| / / / | * D If this is combined with the "skew" effect above, we get a much cleaner graph display for these edges: * F | * | E /|\| | * D Finally, the edge leading from C to A appears jagged as it passes through the commit line for B: | * | C | |/ * | B |/ * A This can be smoothed out so that such edges are easier to read: | * | C | |/ * / B |/ * A Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:53 +00:00
|/
* A
EOF
'
graph: tidy up display of left-skewed merges Currently, when we display a merge whose first parent is already present in a column to the left of the merge commit, we display the first parent as a vertical pipe `|` in the GRAPH_POST_MERGE line and then immediately enter the GRAPH_COLLAPSING state. The first-parent line tracks to the left and all the other parent lines follow it; this creates a "kink" in those lines: | *---. | |\ \ \ |/ / / / | | | * This change tidies the display of such commits such that if the first parent appears to the left of the merge, we render it as a `/` and the second parent as a `|`. This reduces the horizontal and vertical space needed to render the merge, and makes the resulting lines easier to read. | *-. |/|\ \ | | | * If the first parent is separated from the merge by several columns, a horizontal line is drawn in a similar manner to how the GRAPH_COLLAPSING state displays the line. | | | *-. | |_|/|\ \ |/| | | | * This effect is applied to both "normal" two-parent merges, and to octopus merges. It also reduces the vertical space needed for pre-commit lines, as the merge occupies one less column than usual. Before: After: | * | * | |\ | |\ | | \ | * \ | | \ |/|\ \ | *-. \ | |\ \ \ Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:54 +00:00
test_expect_success 'log --graph with left-skewed merge' '
t4215: use helper function to check output When git commands are placed in the upstream of a pipe, their return codes are lost. In this particular case, it is especially bad since we are testing the intricacies of `git log --graph` behavior and if we hit an unexpected failure or segfault, we want to know this. Extract the common output checking logic into check_graph() where we redirect the output of git commands upstream of pipe into a file and have sed read from that file so that git failures are detected. This patch is best viewed with `--color-moved`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-12 18:56:22 +00:00
git checkout --orphan 0_p && test_commit 0_A &&
git checkout -b 0_q 0_p && test_commit 0_B &&
git checkout -b 0_r 0_p &&
test_commit 0_C &&
test_commit 0_D &&
git checkout -b 0_s 0_p && test_commit 0_E &&
git checkout -b 0_t 0_p && git merge --no-ff 0_r^ 0_s -m 0_F &&
git checkout 0_p && git merge --no-ff 0_s -m 0_G &&
git checkout @^ && git merge --no-ff 0_q 0_r 0_t 0_p -m 0_H &&
check_graph <<-\EOF
graph: tidy up display of left-skewed merges Currently, when we display a merge whose first parent is already present in a column to the left of the merge commit, we display the first parent as a vertical pipe `|` in the GRAPH_POST_MERGE line and then immediately enter the GRAPH_COLLAPSING state. The first-parent line tracks to the left and all the other parent lines follow it; this creates a "kink" in those lines: | *---. | |\ \ \ |/ / / / | | | * This change tidies the display of such commits such that if the first parent appears to the left of the merge, we render it as a `/` and the second parent as a `|`. This reduces the horizontal and vertical space needed to render the merge, and makes the resulting lines easier to read. | *-. |/|\ \ | | | * If the first parent is separated from the merge by several columns, a horizontal line is drawn in a similar manner to how the GRAPH_COLLAPSING state displays the line. | | | *-. | |_|/|\ \ |/| | | | * This effect is applied to both "normal" two-parent merges, and to octopus merges. It also reduces the vertical space needed for pre-commit lines, as the merge occupies one less column than usual. Before: After: | * | * | |\ | |\ | | \ | * \ | | \ |/|\ \ | *-. \ | |\ \ \ Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:54 +00:00
*-----. 0_H
|\ \ \ \
| | | | * 0_G
| |_|_|/|
|/| | | |
graph: flatten edges that fuse with their right neighbor When a merge commit is printed and its final parent is the same commit that occupies the column to the right of the merge, this results in a kink in the displayed edges: * | |\ \ | |/ | * Graphs containing these shapes can be hard to read, as the expansion to the right followed immediately by collapsing back to the left creates a lot of zig-zagging edges, especially when many columns are present. We can improve this by eliminating the zig-zag and having the merge's final parent edge fuse immediately with its neighbor: * | |\| | * This reduces the horizontal width for the current commit by 2, and requires one less row, making the graph display more compact. Taken in combination with other graph-smoothing enhancements, it greatly compresses the space needed to display certain histories: * |\ | * * | |\ |\ | | * | * | | | | |\ | | \ | | * | *-. \ | * | | |\ \ \ => |/|\| |/ / / / | | * | | | / | * | | | |/ | |/ | | * * / | * | |/ | |/ * * | |/ * One of the test cases here cannot be correctly rendered in Git v2.23.0; it produces this output following commit E: | | *-. \ 5_E | | |\ \ \ | |/ / / / | | | / _ | |_|/ |/| | The new implementation makes sure that the rightmost edge in this history is not left dangling as above. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:58 +00:00
| | | * | 0_F
| |_|/|\|
|/| | | |
graph: tidy up display of left-skewed merges Currently, when we display a merge whose first parent is already present in a column to the left of the merge commit, we display the first parent as a vertical pipe `|` in the GRAPH_POST_MERGE line and then immediately enter the GRAPH_COLLAPSING state. The first-parent line tracks to the left and all the other parent lines follow it; this creates a "kink" in those lines: | *---. | |\ \ \ |/ / / / | | | * This change tidies the display of such commits such that if the first parent appears to the left of the merge, we render it as a `/` and the second parent as a `|`. This reduces the horizontal and vertical space needed to render the merge, and makes the resulting lines easier to read. | *-. |/|\ \ | | | * If the first parent is separated from the merge by several columns, a horizontal line is drawn in a similar manner to how the GRAPH_COLLAPSING state displays the line. | | | *-. | |_|/|\ \ |/| | | | * This effect is applied to both "normal" two-parent merges, and to octopus merges. It also reduces the vertical space needed for pre-commit lines, as the merge occupies one less column than usual. Before: After: | * | * | |\ | |\ | | \ | * \ | | \ |/|\ \ | *-. \ | |\ \ \ Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:54 +00:00
| | | | * 0_E
| |_|_|/
|/| | |
| | * | 0_D
| | |/
| | * 0_C
| |/
|/|
| * 0_B
|/
* 0_A
EOF
'
graph: commit and post-merge lines for left-skewed merges Following the introduction of "left-skewed" merges, which are merges whose first parent fuses with another edge to its left, we have some more edge cases to deal with in the display of commit and post-merge lines. The current graph code handles the following cases for edges appearing to the right of the commit (*) on commit lines. A 2-way merge is usually followed by vertical lines: | | | | * | | |\ \ An octopus merge (more than two parents) is always followed by edges sloping to the right: | | \ | | \ | *-. \ | *---. \ | |\ \ \ | |\ \ \ \ A 2-way merge is followed by a right-sloping edge if the commit line immediately follows a post-merge line for a commit that appears in the same column as the current commit, or any column to the left of that: | * | * | | |\ | |\ \ | * \ | | * \ | |\ \ | | |\ \ This commit introduces the following new cases for commit lines. If a 2-way merge skews to the left, then the edges to its right are always vertical lines, even if the commit follows a post-merge line: | | | | |\ | * | | * | |/| | |/| | A commit with 3 parents that skews left is followed by vertical edges: | | | | * | |/|\ \ If a 3-way left-skewed merge commit appears immediately after a post-merge line, then it may be followed the right-sloping edges, just like a 2-way merge that is not skewed. | |\ | * \ |/|\ \ Octopus merges with 4 or more parents that skew to the left will always be followed by right-sloping edges, because the existing columns need to expand around the merge. | | \ | *-. \ |/|\ \ \ On post-merge lines, usually all edges following the current commit slope to the right: | * | | | |\ \ \ However, if the commit is a left-skewed 2-way merge, the edges to its right remain vertical. We also need to display a space after the vertical line descending from the commit marker, whereas this line would normally be followed by a backslash. | * | | |/| | | If a left-skewed merge has more than 2 parents, then the edges to its right are still sloped as they bend around the edges introduced by the merge. | * | | |/|\ \ \ To handle these new cases, we need to know not just how many parents each commit has, but how many new columns it adds to the display; this quantity is recorded in the `edges_added` field for the current commit, and `prev_edges_added` field for the previous commit. Here, "column" refers to visual columns, not the logical columns of the `columns` array. This is because even if all the commit's parents end up fusing with existing edges, they initially introduce distinct edges in the commit and post-merge lines before those edges collapse. For example, a 3-way merge whose 2nd and 3rd parents fuse with existing edges still introduces 2 visual columns that affect the display of edges to their right. | | | \ | | *-. \ | | |\ \ \ | |_|/ / / |/| | / / | | |/ / | |/| | | | | | This merge does not introduce any *logical* columns; there are 4 edges before and after this commit once all edges have collapsed. But it does initially introduce 2 new edges that need to be accommodated by the edges to their right. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:55 +00:00
test_expect_success 'log --graph with nested left-skewed merge' '
t4215: use helper function to check output When git commands are placed in the upstream of a pipe, their return codes are lost. In this particular case, it is especially bad since we are testing the intricacies of `git log --graph` behavior and if we hit an unexpected failure or segfault, we want to know this. Extract the common output checking logic into check_graph() where we redirect the output of git commands upstream of pipe into a file and have sed read from that file so that git failures are detected. This patch is best viewed with `--color-moved`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-12 18:56:22 +00:00
git checkout --orphan 1_p &&
test_commit 1_A &&
test_commit 1_B &&
test_commit 1_C &&
git checkout -b 1_q @^ && test_commit 1_D &&
git checkout 1_p && git merge --no-ff 1_q -m 1_E &&
git checkout -b 1_r @~3 && test_commit 1_F &&
git checkout 1_p && git merge --no-ff 1_r -m 1_G &&
git checkout @^^ && git merge --no-ff 1_p -m 1_H &&
check_graph <<-\EOF
graph: commit and post-merge lines for left-skewed merges Following the introduction of "left-skewed" merges, which are merges whose first parent fuses with another edge to its left, we have some more edge cases to deal with in the display of commit and post-merge lines. The current graph code handles the following cases for edges appearing to the right of the commit (*) on commit lines. A 2-way merge is usually followed by vertical lines: | | | | * | | |\ \ An octopus merge (more than two parents) is always followed by edges sloping to the right: | | \ | | \ | *-. \ | *---. \ | |\ \ \ | |\ \ \ \ A 2-way merge is followed by a right-sloping edge if the commit line immediately follows a post-merge line for a commit that appears in the same column as the current commit, or any column to the left of that: | * | * | | |\ | |\ \ | * \ | | * \ | |\ \ | | |\ \ This commit introduces the following new cases for commit lines. If a 2-way merge skews to the left, then the edges to its right are always vertical lines, even if the commit follows a post-merge line: | | | | |\ | * | | * | |/| | |/| | A commit with 3 parents that skews left is followed by vertical edges: | | | | * | |/|\ \ If a 3-way left-skewed merge commit appears immediately after a post-merge line, then it may be followed the right-sloping edges, just like a 2-way merge that is not skewed. | |\ | * \ |/|\ \ Octopus merges with 4 or more parents that skew to the left will always be followed by right-sloping edges, because the existing columns need to expand around the merge. | | \ | *-. \ |/|\ \ \ On post-merge lines, usually all edges following the current commit slope to the right: | * | | | |\ \ \ However, if the commit is a left-skewed 2-way merge, the edges to its right remain vertical. We also need to display a space after the vertical line descending from the commit marker, whereas this line would normally be followed by a backslash. | * | | |/| | | If a left-skewed merge has more than 2 parents, then the edges to its right are still sloped as they bend around the edges introduced by the merge. | * | | |/|\ \ \ To handle these new cases, we need to know not just how many parents each commit has, but how many new columns it adds to the display; this quantity is recorded in the `edges_added` field for the current commit, and `prev_edges_added` field for the previous commit. Here, "column" refers to visual columns, not the logical columns of the `columns` array. This is because even if all the commit's parents end up fusing with existing edges, they initially introduce distinct edges in the commit and post-merge lines before those edges collapse. For example, a 3-way merge whose 2nd and 3rd parents fuse with existing edges still introduces 2 visual columns that affect the display of edges to their right. | | | \ | | *-. \ | | |\ \ \ | |_|/ / / |/| | / / | | |/ / | |/| | | | | | This merge does not introduce any *logical* columns; there are 4 edges before and after this commit once all edges have collapsed. But it does initially introduce 2 new edges that need to be accommodated by the edges to their right. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:55 +00:00
* 1_H
|\
| * 1_G
| |\
| | * 1_F
| * | 1_E
|/| |
| * | 1_D
* | | 1_C
|/ /
graph: smooth appearance of collapsing edges on commit lines When a graph contains edges that are in the process of collapsing to the left, but those edges cross a commit line, the effect is that the edges have a jagged appearance: * |\ | * | \ *-. \ |\ \ \ | | * | | * | | | |/ / * | | |/ / * | |/ * We already takes steps to smooth edges like this when they're expanding; when an edge appears to the right of a merge commit marker on a GRAPH_COMMIT line immediately following a GRAPH_POST_MERGE line, we render it as a `\`: * \ |\ \ | * \ | |\ \ We can make a similar improvement to collapsing edges, making them easier to follow and giving the overall graph a feeling of increased symmetry: * |\ | * | \ *-. \ |\ \ \ | | * | | * | | | |/ / * / / |/ / * / |/ * To do this, we introduce a new special case for edges on GRAPH_COMMIT lines that immediately follow a GRAPH_COLLAPSING line. By retaining a copy of the `mapping` array used to render the GRAPH_COLLAPSING line in the `old_mapping` array, we can determine that an edge is collapsing through the GRAPH_COMMIT line and should be smoothed. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:57 +00:00
* / 1_B
graph: commit and post-merge lines for left-skewed merges Following the introduction of "left-skewed" merges, which are merges whose first parent fuses with another edge to its left, we have some more edge cases to deal with in the display of commit and post-merge lines. The current graph code handles the following cases for edges appearing to the right of the commit (*) on commit lines. A 2-way merge is usually followed by vertical lines: | | | | * | | |\ \ An octopus merge (more than two parents) is always followed by edges sloping to the right: | | \ | | \ | *-. \ | *---. \ | |\ \ \ | |\ \ \ \ A 2-way merge is followed by a right-sloping edge if the commit line immediately follows a post-merge line for a commit that appears in the same column as the current commit, or any column to the left of that: | * | * | | |\ | |\ \ | * \ | | * \ | |\ \ | | |\ \ This commit introduces the following new cases for commit lines. If a 2-way merge skews to the left, then the edges to its right are always vertical lines, even if the commit follows a post-merge line: | | | | |\ | * | | * | |/| | |/| | A commit with 3 parents that skews left is followed by vertical edges: | | | | * | |/|\ \ If a 3-way left-skewed merge commit appears immediately after a post-merge line, then it may be followed the right-sloping edges, just like a 2-way merge that is not skewed. | |\ | * \ |/|\ \ Octopus merges with 4 or more parents that skew to the left will always be followed by right-sloping edges, because the existing columns need to expand around the merge. | | \ | *-. \ |/|\ \ \ On post-merge lines, usually all edges following the current commit slope to the right: | * | | | |\ \ \ However, if the commit is a left-skewed 2-way merge, the edges to its right remain vertical. We also need to display a space after the vertical line descending from the commit marker, whereas this line would normally be followed by a backslash. | * | | |/| | | If a left-skewed merge has more than 2 parents, then the edges to its right are still sloped as they bend around the edges introduced by the merge. | * | | |/|\ \ \ To handle these new cases, we need to know not just how many parents each commit has, but how many new columns it adds to the display; this quantity is recorded in the `edges_added` field for the current commit, and `prev_edges_added` field for the previous commit. Here, "column" refers to visual columns, not the logical columns of the `columns` array. This is because even if all the commit's parents end up fusing with existing edges, they initially introduce distinct edges in the commit and post-merge lines before those edges collapse. For example, a 3-way merge whose 2nd and 3rd parents fuse with existing edges still introduces 2 visual columns that affect the display of edges to their right. | | | \ | | *-. \ | | |\ \ \ | |_|/ / / |/| | / / | | |/ / | |/| | | | | | This merge does not introduce any *logical* columns; there are 4 edges before and after this commit once all edges have collapsed. But it does initially introduce 2 new edges that need to be accommodated by the edges to their right. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:55 +00:00
|/
* 1_A
EOF
'
test_expect_success 'log --graph with nested left-skewed merge following normal merge' '
t4215: use helper function to check output When git commands are placed in the upstream of a pipe, their return codes are lost. In this particular case, it is especially bad since we are testing the intricacies of `git log --graph` behavior and if we hit an unexpected failure or segfault, we want to know this. Extract the common output checking logic into check_graph() where we redirect the output of git commands upstream of pipe into a file and have sed read from that file so that git failures are detected. This patch is best viewed with `--color-moved`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-12 18:56:22 +00:00
git checkout --orphan 2_p &&
test_commit 2_A &&
test_commit 2_B &&
test_commit 2_C &&
git checkout -b 2_q @^^ &&
test_commit 2_D &&
test_commit 2_E &&
git checkout -b 2_r @^ && test_commit 2_F &&
git checkout 2_q &&
git merge --no-ff 2_r -m 2_G &&
git merge --no-ff 2_p^ -m 2_H &&
git checkout -b 2_s @^^ && git merge --no-ff 2_q -m 2_J &&
git checkout 2_p && git merge --no-ff 2_s -m 2_K &&
check_graph <<-\EOF
graph: commit and post-merge lines for left-skewed merges Following the introduction of "left-skewed" merges, which are merges whose first parent fuses with another edge to its left, we have some more edge cases to deal with in the display of commit and post-merge lines. The current graph code handles the following cases for edges appearing to the right of the commit (*) on commit lines. A 2-way merge is usually followed by vertical lines: | | | | * | | |\ \ An octopus merge (more than two parents) is always followed by edges sloping to the right: | | \ | | \ | *-. \ | *---. \ | |\ \ \ | |\ \ \ \ A 2-way merge is followed by a right-sloping edge if the commit line immediately follows a post-merge line for a commit that appears in the same column as the current commit, or any column to the left of that: | * | * | | |\ | |\ \ | * \ | | * \ | |\ \ | | |\ \ This commit introduces the following new cases for commit lines. If a 2-way merge skews to the left, then the edges to its right are always vertical lines, even if the commit follows a post-merge line: | | | | |\ | * | | * | |/| | |/| | A commit with 3 parents that skews left is followed by vertical edges: | | | | * | |/|\ \ If a 3-way left-skewed merge commit appears immediately after a post-merge line, then it may be followed the right-sloping edges, just like a 2-way merge that is not skewed. | |\ | * \ |/|\ \ Octopus merges with 4 or more parents that skew to the left will always be followed by right-sloping edges, because the existing columns need to expand around the merge. | | \ | *-. \ |/|\ \ \ On post-merge lines, usually all edges following the current commit slope to the right: | * | | | |\ \ \ However, if the commit is a left-skewed 2-way merge, the edges to its right remain vertical. We also need to display a space after the vertical line descending from the commit marker, whereas this line would normally be followed by a backslash. | * | | |/| | | If a left-skewed merge has more than 2 parents, then the edges to its right are still sloped as they bend around the edges introduced by the merge. | * | | |/|\ \ \ To handle these new cases, we need to know not just how many parents each commit has, but how many new columns it adds to the display; this quantity is recorded in the `edges_added` field for the current commit, and `prev_edges_added` field for the previous commit. Here, "column" refers to visual columns, not the logical columns of the `columns` array. This is because even if all the commit's parents end up fusing with existing edges, they initially introduce distinct edges in the commit and post-merge lines before those edges collapse. For example, a 3-way merge whose 2nd and 3rd parents fuse with existing edges still introduces 2 visual columns that affect the display of edges to their right. | | | \ | | *-. \ | | |\ \ \ | |_|/ / / |/| | / / | | |/ / | |/| | | | | | This merge does not introduce any *logical* columns; there are 4 edges before and after this commit once all edges have collapsed. But it does initially introduce 2 new edges that need to be accommodated by the edges to their right. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:55 +00:00
* 2_K
|\
| * 2_J
| |\
| | * 2_H
| | |\
| | * | 2_G
| |/| |
| | * | 2_F
| * | | 2_E
| |/ /
| * | 2_D
* | | 2_C
| |/
|/|
* | 2_B
|/
* 2_A
EOF
'
test_expect_success 'log --graph with nested right-skewed merge following left-skewed merge' '
t4215: use helper function to check output When git commands are placed in the upstream of a pipe, their return codes are lost. In this particular case, it is especially bad since we are testing the intricacies of `git log --graph` behavior and if we hit an unexpected failure or segfault, we want to know this. Extract the common output checking logic into check_graph() where we redirect the output of git commands upstream of pipe into a file and have sed read from that file so that git failures are detected. This patch is best viewed with `--color-moved`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-12 18:56:22 +00:00
git checkout --orphan 3_p &&
test_commit 3_A &&
git checkout -b 3_q &&
test_commit 3_B &&
test_commit 3_C &&
git checkout -b 3_r @^ &&
test_commit 3_D &&
git checkout 3_q && git merge --no-ff 3_r -m 3_E &&
git checkout 3_p && git merge --no-ff 3_q -m 3_F &&
git checkout 3_r && test_commit 3_G &&
git checkout 3_p && git merge --no-ff 3_r -m 3_H &&
git checkout @^^ && git merge --no-ff 3_p -m 3_J &&
check_graph <<-\EOF
graph: commit and post-merge lines for left-skewed merges Following the introduction of "left-skewed" merges, which are merges whose first parent fuses with another edge to its left, we have some more edge cases to deal with in the display of commit and post-merge lines. The current graph code handles the following cases for edges appearing to the right of the commit (*) on commit lines. A 2-way merge is usually followed by vertical lines: | | | | * | | |\ \ An octopus merge (more than two parents) is always followed by edges sloping to the right: | | \ | | \ | *-. \ | *---. \ | |\ \ \ | |\ \ \ \ A 2-way merge is followed by a right-sloping edge if the commit line immediately follows a post-merge line for a commit that appears in the same column as the current commit, or any column to the left of that: | * | * | | |\ | |\ \ | * \ | | * \ | |\ \ | | |\ \ This commit introduces the following new cases for commit lines. If a 2-way merge skews to the left, then the edges to its right are always vertical lines, even if the commit follows a post-merge line: | | | | |\ | * | | * | |/| | |/| | A commit with 3 parents that skews left is followed by vertical edges: | | | | * | |/|\ \ If a 3-way left-skewed merge commit appears immediately after a post-merge line, then it may be followed the right-sloping edges, just like a 2-way merge that is not skewed. | |\ | * \ |/|\ \ Octopus merges with 4 or more parents that skew to the left will always be followed by right-sloping edges, because the existing columns need to expand around the merge. | | \ | *-. \ |/|\ \ \ On post-merge lines, usually all edges following the current commit slope to the right: | * | | | |\ \ \ However, if the commit is a left-skewed 2-way merge, the edges to its right remain vertical. We also need to display a space after the vertical line descending from the commit marker, whereas this line would normally be followed by a backslash. | * | | |/| | | If a left-skewed merge has more than 2 parents, then the edges to its right are still sloped as they bend around the edges introduced by the merge. | * | | |/|\ \ \ To handle these new cases, we need to know not just how many parents each commit has, but how many new columns it adds to the display; this quantity is recorded in the `edges_added` field for the current commit, and `prev_edges_added` field for the previous commit. Here, "column" refers to visual columns, not the logical columns of the `columns` array. This is because even if all the commit's parents end up fusing with existing edges, they initially introduce distinct edges in the commit and post-merge lines before those edges collapse. For example, a 3-way merge whose 2nd and 3rd parents fuse with existing edges still introduces 2 visual columns that affect the display of edges to their right. | | | \ | | *-. \ | | |\ \ \ | |_|/ / / |/| | / / | | |/ / | |/| | | | | | This merge does not introduce any *logical* columns; there are 4 edges before and after this commit once all edges have collapsed. But it does initially introduce 2 new edges that need to be accommodated by the edges to their right. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:55 +00:00
* 3_J
|\
| * 3_H
| |\
| | * 3_G
| * | 3_F
|/| |
graph: flatten edges that fuse with their right neighbor When a merge commit is printed and its final parent is the same commit that occupies the column to the right of the merge, this results in a kink in the displayed edges: * | |\ \ | |/ | * Graphs containing these shapes can be hard to read, as the expansion to the right followed immediately by collapsing back to the left creates a lot of zig-zagging edges, especially when many columns are present. We can improve this by eliminating the zig-zag and having the merge's final parent edge fuse immediately with its neighbor: * | |\| | * This reduces the horizontal width for the current commit by 2, and requires one less row, making the graph display more compact. Taken in combination with other graph-smoothing enhancements, it greatly compresses the space needed to display certain histories: * |\ | * * | |\ |\ | | * | * | | | | |\ | | \ | | * | *-. \ | * | | |\ \ \ => |/|\| |/ / / / | | * | | | / | * | | | |/ | |/ | | * * / | * | |/ | |/ * * | |/ * One of the test cases here cannot be correctly rendered in Git v2.23.0; it produces this output following commit E: | | *-. \ 5_E | | |\ \ \ | |/ / / / | | | / _ | |_|/ |/| | The new implementation makes sure that the rightmost edge in this history is not left dangling as above. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:58 +00:00
| * | 3_E
| |\|
graph: commit and post-merge lines for left-skewed merges Following the introduction of "left-skewed" merges, which are merges whose first parent fuses with another edge to its left, we have some more edge cases to deal with in the display of commit and post-merge lines. The current graph code handles the following cases for edges appearing to the right of the commit (*) on commit lines. A 2-way merge is usually followed by vertical lines: | | | | * | | |\ \ An octopus merge (more than two parents) is always followed by edges sloping to the right: | | \ | | \ | *-. \ | *---. \ | |\ \ \ | |\ \ \ \ A 2-way merge is followed by a right-sloping edge if the commit line immediately follows a post-merge line for a commit that appears in the same column as the current commit, or any column to the left of that: | * | * | | |\ | |\ \ | * \ | | * \ | |\ \ | | |\ \ This commit introduces the following new cases for commit lines. If a 2-way merge skews to the left, then the edges to its right are always vertical lines, even if the commit follows a post-merge line: | | | | |\ | * | | * | |/| | |/| | A commit with 3 parents that skews left is followed by vertical edges: | | | | * | |/|\ \ If a 3-way left-skewed merge commit appears immediately after a post-merge line, then it may be followed the right-sloping edges, just like a 2-way merge that is not skewed. | |\ | * \ |/|\ \ Octopus merges with 4 or more parents that skew to the left will always be followed by right-sloping edges, because the existing columns need to expand around the merge. | | \ | *-. \ |/|\ \ \ On post-merge lines, usually all edges following the current commit slope to the right: | * | | | |\ \ \ However, if the commit is a left-skewed 2-way merge, the edges to its right remain vertical. We also need to display a space after the vertical line descending from the commit marker, whereas this line would normally be followed by a backslash. | * | | |/| | | If a left-skewed merge has more than 2 parents, then the edges to its right are still sloped as they bend around the edges introduced by the merge. | * | | |/|\ \ \ To handle these new cases, we need to know not just how many parents each commit has, but how many new columns it adds to the display; this quantity is recorded in the `edges_added` field for the current commit, and `prev_edges_added` field for the previous commit. Here, "column" refers to visual columns, not the logical columns of the `columns` array. This is because even if all the commit's parents end up fusing with existing edges, they initially introduce distinct edges in the commit and post-merge lines before those edges collapse. For example, a 3-way merge whose 2nd and 3rd parents fuse with existing edges still introduces 2 visual columns that affect the display of edges to their right. | | | \ | | *-. \ | | |\ \ \ | |_|/ / / |/| | / / | | |/ / | |/| | | | | | This merge does not introduce any *logical* columns; there are 4 edges before and after this commit once all edges have collapsed. But it does initially introduce 2 new edges that need to be accommodated by the edges to their right. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:55 +00:00
| | * 3_D
| * | 3_C
| |/
| * 3_B
|/
* 3_A
EOF
'
test_expect_success 'log --graph with right-skewed merge following a left-skewed one' '
t4215: use helper function to check output When git commands are placed in the upstream of a pipe, their return codes are lost. In this particular case, it is especially bad since we are testing the intricacies of `git log --graph` behavior and if we hit an unexpected failure or segfault, we want to know this. Extract the common output checking logic into check_graph() where we redirect the output of git commands upstream of pipe into a file and have sed read from that file so that git failures are detected. This patch is best viewed with `--color-moved`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-12 18:56:22 +00:00
git checkout --orphan 4_p &&
test_commit 4_A &&
test_commit 4_B &&
test_commit 4_C &&
git checkout -b 4_q @^^ && test_commit 4_D &&
git checkout -b 4_r 4_p^ && git merge --no-ff 4_q -m 4_E &&
git checkout -b 4_s 4_p^^ &&
git merge --no-ff 4_r -m 4_F &&
git merge --no-ff 4_p -m 4_G &&
git checkout @^^ && git merge --no-ff 4_s -m 4_H &&
check_graph --date-order <<-\EOF
graph: commit and post-merge lines for left-skewed merges Following the introduction of "left-skewed" merges, which are merges whose first parent fuses with another edge to its left, we have some more edge cases to deal with in the display of commit and post-merge lines. The current graph code handles the following cases for edges appearing to the right of the commit (*) on commit lines. A 2-way merge is usually followed by vertical lines: | | | | * | | |\ \ An octopus merge (more than two parents) is always followed by edges sloping to the right: | | \ | | \ | *-. \ | *---. \ | |\ \ \ | |\ \ \ \ A 2-way merge is followed by a right-sloping edge if the commit line immediately follows a post-merge line for a commit that appears in the same column as the current commit, or any column to the left of that: | * | * | | |\ | |\ \ | * \ | | * \ | |\ \ | | |\ \ This commit introduces the following new cases for commit lines. If a 2-way merge skews to the left, then the edges to its right are always vertical lines, even if the commit follows a post-merge line: | | | | |\ | * | | * | |/| | |/| | A commit with 3 parents that skews left is followed by vertical edges: | | | | * | |/|\ \ If a 3-way left-skewed merge commit appears immediately after a post-merge line, then it may be followed the right-sloping edges, just like a 2-way merge that is not skewed. | |\ | * \ |/|\ \ Octopus merges with 4 or more parents that skew to the left will always be followed by right-sloping edges, because the existing columns need to expand around the merge. | | \ | *-. \ |/|\ \ \ On post-merge lines, usually all edges following the current commit slope to the right: | * | | | |\ \ \ However, if the commit is a left-skewed 2-way merge, the edges to its right remain vertical. We also need to display a space after the vertical line descending from the commit marker, whereas this line would normally be followed by a backslash. | * | | |/| | | If a left-skewed merge has more than 2 parents, then the edges to its right are still sloped as they bend around the edges introduced by the merge. | * | | |/|\ \ \ To handle these new cases, we need to know not just how many parents each commit has, but how many new columns it adds to the display; this quantity is recorded in the `edges_added` field for the current commit, and `prev_edges_added` field for the previous commit. Here, "column" refers to visual columns, not the logical columns of the `columns` array. This is because even if all the commit's parents end up fusing with existing edges, they initially introduce distinct edges in the commit and post-merge lines before those edges collapse. For example, a 3-way merge whose 2nd and 3rd parents fuse with existing edges still introduces 2 visual columns that affect the display of edges to their right. | | | \ | | *-. \ | | |\ \ \ | |_|/ / / |/| | / / | | |/ / | |/| | | | | | This merge does not introduce any *logical* columns; there are 4 edges before and after this commit once all edges have collapsed. But it does initially introduce 2 new edges that need to be accommodated by the edges to their right. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:55 +00:00
* 4_H
|\
| * 4_G
| |\
| * | 4_F
|/| |
| * | 4_E
| |\ \
| | * | 4_D
| |/ /
|/| |
| | * 4_C
| |/
| * 4_B
|/
* 4_A
EOF
'
graph: flatten edges that fuse with their right neighbor When a merge commit is printed and its final parent is the same commit that occupies the column to the right of the merge, this results in a kink in the displayed edges: * | |\ \ | |/ | * Graphs containing these shapes can be hard to read, as the expansion to the right followed immediately by collapsing back to the left creates a lot of zig-zagging edges, especially when many columns are present. We can improve this by eliminating the zig-zag and having the merge's final parent edge fuse immediately with its neighbor: * | |\| | * This reduces the horizontal width for the current commit by 2, and requires one less row, making the graph display more compact. Taken in combination with other graph-smoothing enhancements, it greatly compresses the space needed to display certain histories: * |\ | * * | |\ |\ | | * | * | | | | |\ | | \ | | * | *-. \ | * | | |\ \ \ => |/|\| |/ / / / | | * | | | / | * | | | |/ | |/ | | * * / | * | |/ | |/ * * | |/ * One of the test cases here cannot be correctly rendered in Git v2.23.0; it produces this output following commit E: | | *-. \ 5_E | | |\ \ \ | |/ / / / | | | / _ | |_|/ |/| | The new implementation makes sure that the rightmost edge in this history is not left dangling as above. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:58 +00:00
test_expect_success 'log --graph with octopus merge with column joining its penultimate parent' '
t4215: use helper function to check output When git commands are placed in the upstream of a pipe, their return codes are lost. In this particular case, it is especially bad since we are testing the intricacies of `git log --graph` behavior and if we hit an unexpected failure or segfault, we want to know this. Extract the common output checking logic into check_graph() where we redirect the output of git commands upstream of pipe into a file and have sed read from that file so that git failures are detected. This patch is best viewed with `--color-moved`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-12 18:56:22 +00:00
git checkout --orphan 5_p &&
test_commit 5_A &&
git branch 5_q &&
git branch 5_r &&
test_commit 5_B &&
git checkout 5_q && test_commit 5_C &&
git checkout 5_r && test_commit 5_D &&
git checkout 5_p &&
git merge --no-ff 5_q 5_r -m 5_E &&
git checkout 5_q && test_commit 5_F &&
git checkout -b 5_s 5_p^ &&
git merge --no-ff 5_p 5_q -m 5_G &&
git checkout 5_r &&
git merge --no-ff 5_s -m 5_H &&
check_graph <<-\EOF
graph: flatten edges that fuse with their right neighbor When a merge commit is printed and its final parent is the same commit that occupies the column to the right of the merge, this results in a kink in the displayed edges: * | |\ \ | |/ | * Graphs containing these shapes can be hard to read, as the expansion to the right followed immediately by collapsing back to the left creates a lot of zig-zagging edges, especially when many columns are present. We can improve this by eliminating the zig-zag and having the merge's final parent edge fuse immediately with its neighbor: * | |\| | * This reduces the horizontal width for the current commit by 2, and requires one less row, making the graph display more compact. Taken in combination with other graph-smoothing enhancements, it greatly compresses the space needed to display certain histories: * |\ | * * | |\ |\ | | * | * | | | | |\ | | \ | | * | *-. \ | * | | |\ \ \ => |/|\| |/ / / / | | * | | | / | * | | | |/ | |/ | | * * / | * | |/ | |/ * * | |/ * One of the test cases here cannot be correctly rendered in Git v2.23.0; it produces this output following commit E: | | *-. \ 5_E | | |\ \ \ | |/ / / / | | | / _ | |_|/ |/| | The new implementation makes sure that the rightmost edge in this history is not left dangling as above. Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:58 +00:00
* 5_H
|\
| *-. 5_G
| |\ \
| | | * 5_F
| | * | 5_E
| |/|\ \
| |_|/ /
|/| | /
| | |/
* | | 5_D
| | * 5_C
| |/
|/|
| * 5_B
|/
* 5_A
EOF
'
graph: drop assert() for merge with two collapsing parents When "git log --graph" shows a merge commit that has two collapsing lines, like: | | | | * | |_|_|/| |/| | |/ | | |/| | |/| | | * | | * | | | we trigger an assert(): graph.c:1228: graph_output_collapsing_line: Assertion `graph->mapping[i - 3] == target' failed. The assert was introduced by eaf158f8 ("graph API: Use horizontal lines for more compact graphs", 2009-04-21), which is quite old. This assert is trying to say that when we complete a horizontal line with a single slash, it is because we have reached our target. It is actually the _second_ collapsing line that hits this assert. The reason we are in this code path is because we are collapsing the first line, and in that case we are hitting our target now that the horizontal line is complete. However, the second line cannot be a horizontal line, so it will collapse without horizontal lines. In this case, it is inappropriate to assert that we have reached our target, as we need to continue for another column before reaching the target. Dropping the assert is safe here. The new behavior in 0f0f389f12 (graph: tidy up display of left-skewed merges, 2019-10-15) caused the behavior change that made this assertion failure possible. In addition to making the assert possible, it also changed how multiple edges collapse. In a larger example, the current code will output a collapse as follows: | | | | | | * | |_|_|_|_|/|\ |/| | | | |/ / | | | | |/| / | | | |/| |/ | | |/| |/| | |/| |/| | | | |/| | | | | * | | | However, the intended collapse should allow multiple horizontal lines as follows: | | | | | | * | |_|_|_|_|/|\ |/| | | | |/ / | | |_|_|/| / | |/| | | |/ | | | |_|/| | | |/| | | | | * | | | This behavior is not corrected by this change, but is noted for a later update. Helped-by: Jeff King <peff@peff.net> Reported-by: Bradley Smith <brad@brad-smith.co.uk> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-07 21:27:01 +00:00
test_expect_success 'log --graph with multiple tips' '
git checkout --orphan 6_1 &&
test_commit 6_A &&
git branch 6_2 &&
git branch 6_4 &&
test_commit 6_B &&
git branch 6_3 &&
test_commit 6_C &&
git checkout 6_2 && test_commit 6_D &&
git checkout 6_3 && test_commit 6_E &&
git checkout -b 6_5 6_1 &&
git merge --no-ff 6_2 -m 6_F &&
git checkout 6_4 && test_commit 6_G &&
git checkout 6_3 &&
git merge --no-ff 6_4 -m 6_H &&
git checkout 6_1 &&
git merge --no-ff 6_2 -m 6_I &&
check_graph 6_1 6_3 6_5 <<-\EOF
* 6_I
|\
| | * 6_H
| | |\
| | | * 6_G
| | * | 6_E
| | | | * 6_F
| |_|_|/|
|/| | |/
| | |/|
| |/| |
| * | | 6_D
| | |/
| |/|
* | | 6_C
| |/
|/|
* | 6_B
|/
* 6_A
EOF
'
graph: fix lack of color in horizontal lines In some cases, horizontal lines in rendered graphs can lose their coloring. This is due to a use of graph_line_addch() instead of graph_line_write_column(). Using a ternary operator to pick the character is nice for compact code, but we actually need a column to provide the color. Add a test to t4215-log-skewed-merges.sh to prevent regression. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-07 21:27:02 +00:00
test_expect_success 'log --graph with multiple tips and colors' '
test_config log.graphColors red,green,yellow,blue,magenta,cyan &&
cat >expect.colors <<-\EOF &&
* 6_I
<RED>|<RESET><GREEN>\<RESET>
<RED>|<RESET> <GREEN>|<RESET> * 6_H
<RED>|<RESET> <GREEN>|<RESET> <YELLOW>|<RESET><BLUE>\<RESET>
<RED>|<RESET> <GREEN>|<RESET> <YELLOW>|<RESET> * 6_G
<RED>|<RESET> <GREEN>|<RESET> <YELLOW>|<RESET> <BLUE>|<RESET> * 6_F
<RED>|<RESET> <GREEN>|<RESET><RED>_<RESET><YELLOW>|<RESET><RED>_<RESET><BLUE>|<RESET><RED>/<RESET><GREEN>|<RESET>
<RED>|<RESET><RED>/<RESET><GREEN>|<RESET> <YELLOW>|<RESET> <BLUE>|<RESET><GREEN>/<RESET>
<RED>|<RESET> <GREEN>|<RESET> <YELLOW>|<RESET><GREEN>/<RESET><BLUE>|<RESET>
<RED>|<RESET> <GREEN>|<RESET><GREEN>/<RESET><YELLOW>|<RESET> <BLUE>|<RESET>
<RED>|<RESET> <GREEN>|<RESET> * <BLUE>|<RESET> 6_E
<RED>|<RESET> * <CYAN>|<RESET> <BLUE>|<RESET> 6_D
<RED>|<RESET> <BLUE>|<RESET> <CYAN>|<RESET><BLUE>/<RESET>
<RED>|<RESET> <BLUE>|<RESET><BLUE>/<RESET><CYAN>|<RESET>
* <BLUE>|<RESET> <CYAN>|<RESET> 6_C
<CYAN>|<RESET> <BLUE>|<RESET><CYAN>/<RESET>
<CYAN>|<RESET><CYAN>/<RESET><BLUE>|<RESET>
* <BLUE>|<RESET> 6_B
<BLUE>|<RESET><BLUE>/<RESET>
* 6_A
EOF
lib-log-graph: consolidate colored graph cmp logic Signed-off-by: Abhishek Kumar <abhishekkumar8222@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-24 13:38:14 +00:00
lib_test_cmp_colored_graph --date-order --pretty=tformat:%s 6_1 6_3 6_5
graph: fix lack of color in horizontal lines In some cases, horizontal lines in rendered graphs can lose their coloring. This is due to a use of graph_line_addch() instead of graph_line_write_column(). Using a ternary operator to pick the character is nice for compact code, but we actually need a column to provide the color. Add a test to t4215-log-skewed-merges.sh to prevent regression. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-07 21:27:02 +00:00
'
graph: fix collapse of multiple edges This fix resolves the previously-added test_expect_failure in t4215-log-skewed-merges.sh. The issue lies in the "else" condition while updating the mapping inside graph_output_collapsing_line(). In 0f0f389f (graph: tidy up display of left-skewed merges, 2019-10-15), the output of left- skewed merges was changed to allow an immediate horizontal edge in the first parent, output by graph_output_post_merge_line() instead of by graph_output_collapsing_line(). This condensed the first line behavior as follows: Before 0f0f389f: | | | | | | *-. | | | | | | |\ \ | |_|_|_|_|/ | | |/| | | | | / / After 0f0f389f: | | | | | | * | |_|_|_|_|/|\ |/| | | | |/ / | | | | |/| / However, a very subtle issue arose when the second and third parent edges are collapsed in later steps. The second parent edge is now immediately adjacent to a vertical edge. This means that the condition } else if (graph->mapping[i - 1] < 0) { in graph_output_collapsing_line() evaluates as false. The block for this condition was the only place where we connected the target column with the current position with horizontal edge markers. In this case, the final "else" block is run, and the edge is marked as horizontal, but did not back-fill the blank columns between the target and the current edge. Since the second parent edge is marked as horizontal, the third parent edge is not marked as horizontal. This causes the output to continue as follows: Before this change: | | | | | | * | |_|_|_|_|/|\ |/| | | | |/ / | | | | |/| / | | | |/| |/ | | |/| |/| | |/| |/| | | | |/| | | By adding the logic for "filling" a horizontal edge between the target column and the current column, we are able to resolve the issue. After this change: | | | | | | * | |_|_|_|_|/|\ |/| | | | |/ / | | |_|_|/| / | |/| | | |/ | | | |_|/| | | |/| | | This output properly matches the expected blend of the edge behavior before 0f0f389f and the merge commit rendering from 0f0f389f. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-08 04:27:55 +00:00
test_expect_success 'log --graph with multiple tips' '
graph: add test to demonstrate horizontal line bug A previous test in t4215-log-skewed-merges.sh was added to demonstrate exactly the topology of a reported failure in "git log --graph". While investigating the fix, we realized that multiple edges that could collapse with horizontal lines were not doing so. Specifically, examine this section of the graph: | | | | | | * | |_|_|_|_|/|\ |/| | | | |/ / | | | | |/| / | | | |/| |/ | | |/| |/| | |/| |/| | | | |/| | | | | * | | | Document this behavior with a test. This behavior is new, as the behavior in v2.24.1 has the following output: | | | | | | *-. | | | | | | |\ \ | |_|_|_|_|/ / / |/| | | | | / / | | |_|_|_|/ / | |/| | | | / | | | |_|_|/ | | |/| | | | | * | | | The behavior changed logically in 479db18b ("graph: smooth appearance of collapsing edges on commit lines", 2019-10-15), but was actually broken due to an assert() bug in 458152cc ("graph: example of graph output that can be simplified", 2019-10-15). A future change could modify this behavior to do the following instead: | | | | | | * | |_|_|_|_|/|\ |/| | | | |/ / | | |_|_|/| / | |/| | | |/ | | | |_|/| | | |/| | | | | * | | | Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-08 04:27:54 +00:00
git checkout --orphan 7_1 &&
test_commit 7_A &&
test_commit 7_B &&
test_commit 7_C &&
git checkout -b 7_2 7_1~2 &&
test_commit 7_D &&
test_commit 7_E &&
git checkout -b 7_3 7_1~1 &&
test_commit 7_F &&
test_commit 7_G &&
git checkout -b 7_4 7_2~1 &&
test_commit 7_H &&
git checkout -b 7_5 7_1~2 &&
test_commit 7_I &&
git checkout -b 7_6 7_3~1 &&
test_commit 7_J &&
git checkout -b M_1 7_1 &&
git merge --no-ff 7_2 -m 7_M1 &&
git checkout -b M_3 7_3 &&
git merge --no-ff 7_4 -m 7_M2 &&
git checkout -b M_5 7_5 &&
git merge --no-ff 7_6 -m 7_M3 &&
git checkout -b M_7 7_1 &&
git merge --no-ff 7_2 7_3 -m 7_M4 &&
check_graph M_1 M_3 M_5 M_7 <<-\EOF
* 7_M1
|\
| | * 7_M2
| | |\
| | | * 7_H
| | | | * 7_M3
| | | | |\
| | | | | * 7_J
| | | | * | 7_I
| | | | | | * 7_M4
| |_|_|_|_|/|\
|/| | | | |/ /
| | |_|_|/| /
| |/| | | |/
| | | |_|/|
| | |/| | |
| | * | | | 7_G
| | | |_|/
| | |/| |
| | * | | 7_F
| * | | | 7_E
| | |/ /
| |/| |
| * | | 7_D
| | |/
| |/|
* | | 7_C
| |/
|/|
* | 7_B
|/
* 7_A
EOF
'
graph: example of graph output that can be simplified The commits following this one introduce a series of improvements to the layout of graphs, tidying up a few edge cases, namely: - merge whose first parent fuses with an existing column to the left - merge whose last parent fuses with its immediate neighbor on the right - edges that collapse to the left above and below a commit line This test case exemplifies these cases and provides a motivating example of the kind of history I'm aiming to clear up. The first parent of merge E is the same as the parent of H, so those edges fuse together. * H | | *-. E | |\ \ |/ / / | * B We can "skew" the display of this merge so that it doesn't introduce additional columns that immediately collapse: * H | | * E |/|\ | * B The last parent of E is D, the same as the parent of F which is the edge to the right of the merge. * F | \ *-. \ E |\ \ \ / / / / | / |/ * D The two edges leading to D could be fused sooner: rather than expanding the F edge around the merge and then letting the edges collapse, the F edge could fuse with the E edge in the post-merge line: * F | \ *-. | E |\ \| / / / | * D If this is combined with the "skew" effect above, we get a much cleaner graph display for these edges: * F | * | E /|\| | * D Finally, the edge leading from C to A appears jagged as it passes through the commit line for B: | * | C | |/ * | B |/ * A This can be smoothed out so that such edges are easier to read: | * | C | |/ * / B |/ * A Signed-off-by: James Coglan <jcoglan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15 23:47:53 +00:00
test_done
Reference in a new issue Copy permalink