2019-10-15 23:47:53 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='git log --graph of skewed merges'
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
2019-11-12 18:56:22 +00:00
|
|
|
check_graph () {
|
|
|
|
cat >expect &&
|
|
|
|
git log --graph --pretty=tformat:%s "$@" >actual.raw &&
|
|
|
|
sed "s/ *$//" actual.raw >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
}
|
|
|
|
|
2019-10-15 23:47:53 +00:00
|
|
|
test_expect_success 'log --graph with merge fusing with its left and right neighbors' '
|
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
|
2019-10-15 23:47:53 +00:00
|
|
|
* H
|
|
|
|
|\
|
|
|
|
| * G
|
|
|
|
| |\
|
|
|
|
| | * F
|
2019-10-15 23:47:58 +00:00
|
|
|
| * | E
|
|
|
|
|/|\|
|
2019-10-15 23:47:53 +00:00
|
|
|
| | * D
|
|
|
|
| * | C
|
|
|
|
| |/
|
2019-10-15 23:47:57 +00:00
|
|
|
* / B
|
2019-10-15 23:47:53 +00:00
|
|
|
|/
|
|
|
|
* A
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
2019-10-15 23:47:54 +00:00
|
|
|
test_expect_success 'log --graph with left-skewed merge' '
|
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
|
2019-10-15 23:47:54 +00:00
|
|
|
*-----. 0_H
|
|
|
|
|\ \ \ \
|
|
|
|
| | | | * 0_G
|
|
|
|
| |_|_|/|
|
|
|
|
|/| | | |
|
2019-10-15 23:47:58 +00:00
|
|
|
| | | * | 0_F
|
|
|
|
| |_|/|\|
|
|
|
|
|/| | | |
|
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' '
|
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
|
|
|
|
|/ /
|
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' '
|
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' '
|
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
|
|
|
|
|/| |
|
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' '
|
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
|
|
|
|
'
|
|
|
|
|
2019-10-15 23:47:58 +00:00
|
|
|
test_expect_success 'log --graph with octopus merge with column joining its penultimate parent' '
|
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
|
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
|
|
|
|
'
|
|
|
|
|
2019-10-15 23:47:53 +00:00
|
|
|
test_done
|