@matheusbsbs / matheus-bagliano / commits / d62893ecc1

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>

James Coglan committed Oct 15, 2019 at 23:47 UTC d62893ecc125767d44a194279bcaffa0d02d2572
2 files changed +203 -7
graph.c
+58 -5
@@ -216,6 +216,46 @@ struct git_graph {
216 * |/| | | | | | | | | | *
217 */
218 int merge_layout;
219 + /*
220 + * The number of columns added to the graph by the current commit. For
221 + * 2-way and octopus merges, this is is usually one less than the
222 + * number of parents:
223 + *
224 + * | | | | | \
225 + * | * | | *---. \
226 + * | |\ \ | |\ \ \ \
227 + * | | | | | | | | | |
228 + *
229 + * num_parents: 2 num_parents: 4
230 + * edges_added: 1 edges_added: 3
231 + *
232 + * For left-skewed merges, the first parent fuses with its neighbor and
233 + * so one less column is added:
234 + *
235 + * | | | | | \
236 + * | * | | *-. \
237 + * |/| | |/|\ \ \
238 + * | | | | | | | |
239 + *
240 + * num_parents: 2 num_parents: 4
241 + * edges_added: 0 edges_added: 2
242 + *
243 + * This number determines how edges to the right of the merge are
244 + * displayed in commit and post-merge lines; if no columns have been
245 + * added then a vertical line should be used where a right-tracking
246 + * line would otherwise be used.
247 + *
248 + * | * \ | * |
249 + * | |\ \ |/| |
250 + * | | * \ | * |
251 + */
252 + int edges_added;
253 + /*
254 + * The number of columns added by the previous commit, which is used to
255 + * smooth edges appearing to the right of a commit in a commit line
256 + * following a post-merge line.
257 + */
258 + int prev_edges_added;
259 /*
260 * The maximum number of columns that can be stored in the columns
261 * and new_columns arrays. This is also half the number of entries
@@ -328,6 +368,8 @@ struct git_graph *graph_init(struct rev_info *opt)
368 graph->commit_index = 0;
369 graph->prev_commit_index = 0;
370 graph->merge_layout = 0;
371 + graph->edges_added = 0;
372 + graph->prev_edges_added = 0;
373 graph->num_columns = 0;
374 graph->num_new_columns = 0;
375 graph->mapping_size = 0;
@@ -689,6 +731,9 @@ void graph_update(struct git_graph *graph, struct commit *commit)
731 */
732 graph_update_columns(graph);
733
734 + graph->prev_edges_added = graph->edges_added;
735 + graph->edges_added = graph->num_parents + graph->merge_layout - 2;
736 +
737 graph->expansion_row = 0;
738
739 /*
@@ -947,12 +992,13 @@ static void graph_output_commit_line(struct git_graph *graph, struct graph_line
992
993 if (graph->num_parents > 2)
994 graph_draw_octopus_merge(graph, line);
950 - } else if (seen_this && (graph->num_parents > 2)) {
995 + } else if (seen_this && (graph->edges_added > 1)) {
996 graph_line_write_column(line, col, '\\');
952 - } else if (seen_this && (graph->num_parents == 2)) {
997 + } else if (seen_this && (graph->edges_added == 1)) {
998 /*
954 - * This is a 2-way merge commit.
955 - * There is no GRAPH_PRE_COMMIT stage for 2-way
999 + * This is either a right-skewed 2-way merge
1000 + * commit, or a left-skewed 3-way merge.
1001 + * There is no GRAPH_PRE_COMMIT stage for such
1002 * merges, so this is the first line of output
1003 * for this commit. Check to see what the previous
1004 * line of output was.
@@ -964,6 +1010,7 @@ static void graph_output_commit_line(struct git_graph *graph, struct graph_line
1010 * makes the output look nicer.
1011 */
1012 if (graph->prev_state == GRAPH_POST_MERGE &&
1013 + graph->prev_edges_added > 0 &&
1014 graph->prev_commit_index < i)
1015 graph_line_write_column(line, col, '\\');
1016 else
@@ -1033,8 +1080,14 @@ static void graph_output_post_merge_line(struct git_graph *graph, struct graph_l
1080 else
1081 idx++;
1082 }
1083 + if (graph->edges_added == 0)
1084 + graph_line_addch(line, ' ');
1085 +
1086 } else if (seen_this) {
1037 - graph_line_write_column(line, col, '\\');
1087 + if (graph->edges_added > 0)
1088 + graph_line_write_column(line, col, '\\');
1089 + else
1090 + graph_line_write_column(line, col, '|');
1091 graph_line_addch(line, ' ');
1092 } else {
1093 graph_line_write_column(line, col, '|');
t/t4215-log-skewed-merges.sh
+145 -2
@@ -11,7 +11,7 @@ test_expect_success 'log --graph with merge fusing with its left and right neigh
11 | * G
12 | |\
13 | | * F
14 - | * \ E
14 + | * | E
15 |/|\ \
16 | | |/
17 | | * D
@@ -43,7 +43,7 @@ test_expect_success 'log --graph with left-skewed merge' '
43 | | | | * 0_G
44 | |_|_|/|
45 |/| | | |
46 - | | | * \ 0_F
46 + | | | * | 0_F
47 | |_|/|\ \
48 |/| | | |/
49 | | | | * 0_E
@@ -73,4 +73,147 @@ test_expect_success 'log --graph with left-skewed merge' '
73 test_cmp expect actual
74 '
75
76 +test_expect_success 'log --graph with nested left-skewed merge' '
77 + cat >expect <<-\EOF &&
78 + * 1_H
79 + |\
80 + | * 1_G
81 + | |\
82 + | | * 1_F
83 + | * | 1_E
84 + |/| |
85 + | * | 1_D
86 + * | | 1_C
87 + |/ /
88 + * | 1_B
89 + |/
90 + * 1_A
91 + EOF
92 +
93 + git checkout --orphan 1_p &&
94 + test_commit 1_A &&
95 + test_commit 1_B &&
96 + test_commit 1_C &&
97 + git checkout -b 1_q @^ && test_commit 1_D &&
98 + git checkout 1_p && git merge --no-ff 1_q -m 1_E &&
99 + git checkout -b 1_r @~3 && test_commit 1_F &&
100 + git checkout 1_p && git merge --no-ff 1_r -m 1_G &&
101 + git checkout @^^ && git merge --no-ff 1_p -m 1_H &&
102 +
103 + git log --graph --pretty=tformat:%s | sed "s/ *$//" >actual &&
104 + test_cmp expect actual
105 +'
106 +
107 +test_expect_success 'log --graph with nested left-skewed merge following normal merge' '
108 + cat >expect <<-\EOF &&
109 + * 2_K
110 + |\
111 + | * 2_J
112 + | |\
113 + | | * 2_H
114 + | | |\
115 + | | * | 2_G
116 + | |/| |
117 + | | * | 2_F
118 + | * | | 2_E
119 + | |/ /
120 + | * | 2_D
121 + * | | 2_C
122 + | |/
123 + |/|
124 + * | 2_B
125 + |/
126 + * 2_A
127 + EOF
128 +
129 + git checkout --orphan 2_p &&
130 + test_commit 2_A &&
131 + test_commit 2_B &&
132 + test_commit 2_C &&
133 + git checkout -b 2_q @^^ &&
134 + test_commit 2_D &&
135 + test_commit 2_E &&
136 + git checkout -b 2_r @^ && test_commit 2_F &&
137 + git checkout 2_q &&
138 + git merge --no-ff 2_r -m 2_G &&
139 + git merge --no-ff 2_p^ -m 2_H &&
140 + git checkout -b 2_s @^^ && git merge --no-ff 2_q -m 2_J &&
141 + git checkout 2_p && git merge --no-ff 2_s -m 2_K &&
142 +
143 + git log --graph --pretty=tformat:%s | sed "s/ *$//" >actual &&
144 + test_cmp expect actual
145 +'
146 +
147 +test_expect_success 'log --graph with nested right-skewed merge following left-skewed merge' '
148 + cat >expect <<-\EOF &&
149 + * 3_J
150 + |\
151 + | * 3_H
152 + | |\
153 + | | * 3_G
154 + | * | 3_F
155 + |/| |
156 + | * | 3_E
157 + | |\ \
158 + | | |/
159 + | | * 3_D
160 + | * | 3_C
161 + | |/
162 + | * 3_B
163 + |/
164 + * 3_A
165 + EOF
166 +
167 + git checkout --orphan 3_p &&
168 + test_commit 3_A &&
169 + git checkout -b 3_q &&
170 + test_commit 3_B &&
171 + test_commit 3_C &&
172 + git checkout -b 3_r @^ &&
173 + test_commit 3_D &&
174 + git checkout 3_q && git merge --no-ff 3_r -m 3_E &&
175 + git checkout 3_p && git merge --no-ff 3_q -m 3_F &&
176 + git checkout 3_r && test_commit 3_G &&
177 + git checkout 3_p && git merge --no-ff 3_r -m 3_H &&
178 + git checkout @^^ && git merge --no-ff 3_p -m 3_J &&
179 +
180 + git log --graph --pretty=tformat:%s | sed "s/ *$//" >actual &&
181 + test_cmp expect actual
182 +'
183 +
184 +test_expect_success 'log --graph with right-skewed merge following a left-skewed one' '
185 + cat >expect <<-\EOF &&
186 + * 4_H
187 + |\
188 + | * 4_G
189 + | |\
190 + | * | 4_F
191 + |/| |
192 + | * | 4_E
193 + | |\ \
194 + | | * | 4_D
195 + | |/ /
196 + |/| |
197 + | | * 4_C
198 + | |/
199 + | * 4_B
200 + |/
201 + * 4_A
202 + EOF
203 +
204 + git checkout --orphan 4_p &&
205 + test_commit 4_A &&
206 + test_commit 4_B &&
207 + test_commit 4_C &&
208 + git checkout -b 4_q @^^ && test_commit 4_D &&
209 + git checkout -b 4_r 4_p^ && git merge --no-ff 4_q -m 4_E &&
210 + git checkout -b 4_s 4_p^^ &&
211 + git merge --no-ff 4_r -m 4_F &&
212 + git merge --no-ff 4_p -m 4_G &&
213 + git checkout @^^ && git merge --no-ff 4_s -m 4_H &&
214 +
215 + git log --graph --date-order --pretty=tformat:%s | sed "s/ *$//" >actual &&
216 + test_cmp expect actual
217 +'
218 +
219 test_done