From: James Coglan <jcoglan@gmail.com>
To: Derrick Stolee <stolee@gmail.com>,
James Coglan via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 07/11] graph: commit and post-merge lines for left-skewed merges
Date: Fri, 11 Oct 2019 18:04:21 +0100 [thread overview]
Message-ID: <204c7479-c78d-54ff-5ece-397b4c31804c@gmail.com> (raw)
In-Reply-To: <9fe7f2d9-2108-5cf6-dcd7-06d91e74e98b@gmail.com>
On 10/10/2019 18:49, Derrick Stolee wrote:
> On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote:
>> From: James Coglan <jcoglan@gmail.com>
>>
>> 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>
>> ---
>> graph.c | 63 +++++++++++++--
>> t/t4215-log-skewed-merges.sh | 151 +++++++++++++++++++++++++++++++++++
>> 2 files changed, 209 insertions(+), 5 deletions(-)
>>
>> diff --git a/graph.c b/graph.c
>> index 9136173e03..fb2e42850f 100644
>> --- a/graph.c
>> +++ b/graph.c
>> @@ -197,6 +197,46 @@ struct git_graph {
>> * |/| | | | | | | | | | *
>> */
>> int merge_layout;
>> + /*
>> + * The number of columns added to the graph by the current commit. For
>> + * 2-way and octopus merges, this is is usually one less than the
>> + * number of parents:
>> + *
>> + * | | | | | \
>> + * | * | | *---. \
>> + * | |\ \ | |\ \ \ \
>> + * | | | | | | | | | |
>> + *
>> + * num_parents: 2 num_parents: 4
>> + * edges_added: 1 edges_added: 3
>> + *
>> + * For left-skewed merges, the first parent fuses with its neighbor and
>> + * so one less column is added:
>> + *
>> + * | | | | | \
>> + * | * | | *-. \
>> + * |/| | |/|\ \ \
>> + * | | | | | | | |
>> + *
>> + * num_parents: 2 num_parents: 4
>> + * edges_added: 0 edges_added: 2
>> + *
>> + * This number determines how edges to the right of the merge are
>> + * displayed in commit and post-merge lines; if no columns have been
>> + * added then a vertical line should be used where a right-tracking
>> + * line would otherwise be used.
>> + *
>> + * | * \ | * |
>> + * | |\ \ |/| |
>> + * | | * \ | * |
>> + */
>> + int edges_added;
>> + /*
>> + * The number of columns added by the previous commit, which is used to
>> + * smooth edges appearing to the right of a commit in a commit line
>> + * following a post-merge line.
>> + */
>> + int prev_edges_added;
>> /*
>> * The maximum number of columns that can be stored in the columns
>> * and new_columns arrays. This is also half the number of entries
>> @@ -309,6 +349,8 @@ struct git_graph *graph_init(struct rev_info *opt)
>> graph->commit_index = 0;
>> graph->prev_commit_index = 0;
>> graph->merge_layout = 0;
>> + graph->edges_added = 0;
>> + graph->prev_edges_added = 0;
>> graph->num_columns = 0;
>> graph->num_new_columns = 0;
>> graph->mapping_size = 0;
>> @@ -670,6 +712,9 @@ void graph_update(struct git_graph *graph, struct commit *commit)
>> */
>> graph_update_columns(graph);
>>
>> + graph->prev_edges_added = graph->edges_added;
>> + graph->edges_added = graph->num_parents + graph->merge_layout - 2;
>> +
>> graph->expansion_row = 0;
>>
>> /*
>> @@ -943,12 +988,13 @@ static void graph_output_commit_line(struct git_graph *graph, struct strbuf *sb)
>>
>> if (graph->num_parents > 2)
>> graph_draw_octopus_merge(graph, sb);
>> - } else if (seen_this && (graph->num_parents > 2)) {
>> + } else if (seen_this && (graph->edges_added > 1)) {
>> strbuf_write_column(sb, col, '\\');
>> - } else if (seen_this && (graph->num_parents == 2)) {
>> + } else if (seen_this && (graph->edges_added == 1)) {
>> /*
>> - * This is a 2-way merge commit.
>> - * There is no GRAPH_PRE_COMMIT stage for 2-way
>> + * This is either a right-skewed 2-way merge
>> + * commit, or a left-skewed 3-way merge.
>> + * There is no GRAPH_PRE_COMMIT stage for such
>> * merges, so this is the first line of output
>> * for this commit. Check to see what the previous
>> * line of output was.
>> @@ -960,6 +1006,7 @@ static void graph_output_commit_line(struct git_graph *graph, struct strbuf *sb)
>> * makes the output look nicer.
>> */
>> if (graph->prev_state == GRAPH_POST_MERGE &&
>> + graph->prev_edges_added > 0 &&
>> graph->prev_commit_index < i)
>> strbuf_write_column(sb, col, '\\');
>> else
>> @@ -1031,8 +1078,14 @@ static void graph_output_post_merge_line(struct git_graph *graph, struct strbuf
>> else
>> idx++;
>> }
>> + if (graph->edges_added == 0)
>> + strbuf_addch(sb, ' ');
>> +
>> } else if (seen_this) {
>> - strbuf_write_column(sb, col, '\\');
>> + if (graph->edges_added > 0)
>> + strbuf_write_column(sb, col, '\\');
>> + else
>> + strbuf_write_column(sb, col, '|');
>> strbuf_addch(sb, ' ');
>> } else {
>> strbuf_write_column(sb, col, '|');
>> diff --git a/t/t4215-log-skewed-merges.sh b/t/t4215-log-skewed-merges.sh
>> index cfaba40f97..e479d6e676 100755
>> --- a/t/t4215-log-skewed-merges.sh
>> +++ b/t/t4215-log-skewed-merges.sh
>> @@ -39,4 +39,155 @@ test_expect_success 'log --graph with left-skewed merge' '
>> test_cmp expect actual
>> '
>>
>> +test_expect_success 'setup nested left-skewed merge' '
>> + 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
>> +'
>> +
>> +cat > expect <<\EOF
>> +* 1_H
>> +|\
>> +| * 1_G
>> +| |\
>> +| | * 1_F
>> +| * | 1_E
>> +|/| |
>> +| * | 1_D
>> +* | | 1_C
>> +|/ /
>> +* | 1_B
>> +|/
>> +* 1_A
>> +EOF
>> +
>> +test_expect_success 'log --graph with nested left-skewed merge' '
>> + git log --graph --pretty=tformat:%s | sed "s/ *$//" > actual &&
>> + test_cmp expect actual
>> +'
>
> I should have noticed in your earlier commits, but why don't you keep
> the output inside the test suite? You can start with "cat >expect <<-EOF"
> to have it ignore leading whitespace. Sorry if there's something else about
> this that is causing issues.
I was following a pattern used in t/t4202-log.sh. I believe it was easier to debug these tests with the setup and expectations split into separate blocks, but I wouldn't be opposed to merging them.
>> +
>> +test_expect_success 'setup nested left-skewed merge following normal merge' '
>> + 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
>> +'
>> +
>> +cat > expect <<\EOF
>> +* 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 left-skewed merge following normal merge' '
>> + git log --graph --pretty=tformat:%s | sed "s/ *$//" > actual &&
>> + test_cmp expect actual
>> +'
>> +
>> +test_expect_success 'setup nested right-skewed merge following left-skewed merge' '
>> + 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
>> +'
>> +
>> +cat > expect <<\EOF
>> +* 3_J
>> +|\
>> +| * 3_H
>> +| |\
>> +| | * 3_G
>> +| * | 3_F
>> +|/| |
>> +| * | 3_E
>> +| |\ \
>> +| | |/
>> +| | * 3_D
>> +| * | 3_C
>> +| |/
>> +| * 3_B
>> +|/
>> +* 3_A
>> +EOF
>> +
>> +test_expect_success 'log --graph with nested right-skewed merge following left-skewed merge' '
>> + git log --graph --pretty=tformat:%s | sed "s/ *$//" > actual &&
>> + test_cmp expect actual
>> +'
>> +
>> +test_expect_success 'setup right-skewed merge following a left-skewed one' '
>> + 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
>> +'
>> +
>> +cat > expect <<\EOF
>> +* 4_H
>> +|\
>> +| * 4_G
>> +| |\
>> +| * | 4_F
>> +|/| |
>> +| * | 4_E
>> +| |\ \
>> +| | * | 4_D
>> +| |/ /
>> +|/| |
>> +| | * 4_C
>> +| |/
>> +| * 4_B
>> +|/
>> +* 4_A
>> +EOF
>> +
>> +test_expect_success 'log --graph with right-skewed merge following a left-skewed one' '
>> + git log --graph --date-order --pretty=tformat:%s | sed "s/ *$//" > actual &&
>> + test_cmp expect actual
>> +'
>> +
>> test_done
>>
>
next prev parent reply other threads:[~2019-10-11 17:04 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 16:13 [PATCH 00/11] Improve the readability of log --graph output James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 01/11] graph: automatically track visible width of `strbuf` James Coglan via GitGitGadget
2019-10-10 21:07 ` Johannes Schindelin
2019-10-10 23:05 ` Denton Liu
2019-10-11 0:49 ` Derrick Stolee
2019-10-11 1:42 ` Junio C Hamano
2019-10-11 5:01 ` Denton Liu
2019-10-11 16:02 ` Johannes Schindelin
2019-10-11 17:20 ` James Coglan
2019-10-12 0:27 ` Junio C Hamano
2019-10-12 16:22 ` Johannes Schindelin
2019-10-14 12:55 ` James Coglan
2019-10-14 13:01 ` James Coglan
2019-10-16 2:15 ` Junio C Hamano
2019-10-11 1:40 ` Junio C Hamano
2019-10-11 17:08 ` James Coglan
2019-10-10 16:13 ` [PATCH 02/11] graph: reuse `find_new_column_by_commit()` James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 03/11] graph: reduce duplication in `graph_insert_into_new_columns()` James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 04/11] graph: remove `mapping_idx` and `graph_update_width()` James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 05/11] graph: extract logic for moving to GRAPH_PRE_COMMIT state James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 06/11] graph: tidy up display of left-skewed merges James Coglan via GitGitGadget
2019-10-10 17:19 ` Derrick Stolee
2019-10-11 16:50 ` James Coglan
2019-10-12 1:36 ` Derrick Stolee
2019-10-14 13:11 ` James Coglan
2019-10-10 16:13 ` [PATCH 07/11] graph: commit and post-merge lines for " James Coglan via GitGitGadget
2019-10-10 17:49 ` Derrick Stolee
2019-10-11 17:04 ` James Coglan [this message]
2019-10-13 6:56 ` Jeff King
2019-10-14 15:38 ` James Coglan
2019-10-14 17:41 ` Derrick Stolee
2019-10-14 20:42 ` Johannes Schindelin
2019-10-10 16:13 ` [PATCH 08/11] graph: rename `new_mapping` to `old_mapping` James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 09/11] graph: smooth appearance of collapsing edges on commit lines James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 10/11] graph: flatten edges that join to their right neighbor James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 11/11] graph: fix coloring of octopus dashes James Coglan via GitGitGadget
2019-10-10 18:16 ` Denton Liu
2019-10-10 18:28 ` Denton Liu
2019-10-13 7:22 ` Jeff King
2019-10-10 17:54 ` [PATCH 00/11] Improve the readability of log --graph output Derrick Stolee
2019-10-13 7:15 ` Jeff King
2019-10-14 15:49 ` James Coglan
2019-10-15 23:40 ` [PATCH v2 00/13] " James Coglan via GitGitGadget
2019-10-15 23:40 ` [PATCH v2 01/13] graph: automatically track display width of graph lines James Coglan via GitGitGadget
2019-10-15 23:40 ` [PATCH v2 02/13] graph: handle line padding in `graph_next_line()` James Coglan via GitGitGadget
2019-10-15 23:40 ` [PATCH v2 03/13] graph: reuse `find_new_column_by_commit()` James Coglan via GitGitGadget
2019-10-15 23:40 ` [PATCH v2 04/13] graph: reduce duplication in `graph_insert_into_new_columns()` James Coglan via GitGitGadget
2019-10-15 23:40 ` [PATCH v2 05/13] graph: remove `mapping_idx` and `graph_update_width()` James Coglan via GitGitGadget
2019-10-15 23:40 ` [PATCH v2 06/13] graph: extract logic for moving to GRAPH_PRE_COMMIT state James Coglan via GitGitGadget
2019-10-15 23:40 ` [PATCH v2 07/13] graph: example of graph output that can be simplified James Coglan via GitGitGadget
2019-10-15 23:40 ` [PATCH v2 08/13] graph: tidy up display of left-skewed merges James Coglan via GitGitGadget
2019-10-15 23:41 ` [PATCH v2 09/13] graph: commit and post-merge lines for " James Coglan via GitGitGadget
2019-10-15 23:41 ` [PATCH v2 10/13] graph: rename `new_mapping` to `old_mapping` James Coglan via GitGitGadget
2019-10-15 23:41 ` [PATCH v2 11/13] graph: smooth appearance of collapsing edges on commit lines James Coglan via GitGitGadget
2019-10-15 23:41 ` [PATCH v2 12/13] graph: flatten edges that fuse with their right neighbor James Coglan via GitGitGadget
2019-10-15 23:41 ` [PATCH v2 13/13] graph: fix coloring of octopus dashes James Coglan via GitGitGadget
2019-10-15 23:47 ` [PATCH v3 00/13] Improve the readability of log --graph output James Coglan via GitGitGadget
2019-10-15 23:47 ` [PATCH v3 01/13] graph: automatically track display width of graph lines James Coglan via GitGitGadget
2019-10-16 3:35 ` Junio C Hamano
2019-10-16 5:10 ` Junio C Hamano
2019-10-15 23:47 ` [PATCH v3 02/13] graph: handle line padding in `graph_next_line()` James Coglan via GitGitGadget
2019-10-16 3:37 ` Junio C Hamano
2019-10-15 23:47 ` [PATCH v3 03/13] graph: reuse `find_new_column_by_commit()` James Coglan via GitGitGadget
2019-10-15 23:47 ` [PATCH v3 04/13] graph: reduce duplication in `graph_insert_into_new_columns()` James Coglan via GitGitGadget
2019-10-15 23:47 ` [PATCH v3 05/13] graph: remove `mapping_idx` and `graph_update_width()` James Coglan via GitGitGadget
2019-10-15 23:47 ` [PATCH v3 06/13] graph: extract logic for moving to GRAPH_PRE_COMMIT state James Coglan via GitGitGadget
2019-10-15 23:47 ` [PATCH v3 07/13] graph: example of graph output that can be simplified James Coglan via GitGitGadget
2019-10-17 12:30 ` Derrick Stolee
2019-10-18 15:21 ` SZEDER Gábor
2019-11-12 1:08 ` [PATCH] t4215: don't put git commands upstream of pipe Denton Liu
2019-11-12 6:57 ` Junio C Hamano
2019-11-12 10:54 ` SZEDER Gábor
2019-11-12 18:56 ` [PATCH v3] t4215: use helper function to check output Denton Liu
2019-11-13 2:05 ` Junio C Hamano
2019-10-15 23:47 ` [PATCH v3 08/13] graph: tidy up display of left-skewed merges James Coglan via GitGitGadget
2019-10-16 4:00 ` Junio C Hamano
2019-10-17 12:34 ` Derrick Stolee
2019-10-18 0:49 ` Junio C Hamano
2019-10-15 23:47 ` [PATCH v3 09/13] graph: commit and post-merge lines for " James Coglan via GitGitGadget
2019-10-15 23:47 ` [PATCH v3 10/13] graph: rename `new_mapping` to `old_mapping` James Coglan via GitGitGadget
2019-10-15 23:47 ` [PATCH v3 11/13] graph: smooth appearance of collapsing edges on commit lines James Coglan via GitGitGadget
2019-10-15 23:47 ` [PATCH v3 12/13] graph: flatten edges that fuse with their right neighbor James Coglan via GitGitGadget
2019-10-15 23:47 ` [PATCH v3 13/13] graph: fix coloring of octopus dashes James Coglan via GitGitGadget
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=204c7479-c78d-54ff-5ece-397b4c31804c@gmail.com \
--to=jcoglan@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=stolee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).