[PATCH v3 10/13] graph: rename `new_mapping` to `old_mapping`

From: James Coglan The change I'm about to make requires being able to inspect the mapping array that was used to render the last GRAPH_COLLAPSING line while rendering a GRAPH_COMMIT line. The `new_mapping` array currently exists as a pre-allocated space for computing the next `mapping` array dur

[PATCH v3 13/13] graph: fix coloring of octopus dashes

From: James Coglan In 04005834ed ("log: fix coloring of certain octopus merge shapes", 2018-09-01) there is a fix for the coloring of dashes following an octopus merge. It makes a distinction between the case where all parents introduce a new column, versus the case where the first parent collaps

[PATCH v3 12/13] graph: flatten edges that fuse with their right neighbor

From: James Coglan 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 t

[PATCH v3 08/13] graph: tidy up display of left-skewed merges

From: James Coglan 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 tra

[PATCH v3 03/13] graph: reuse `find_new_column_by_commit()`

From: James Coglan I will shortly be making some changes to `graph_insert_into_new_columns()` and so am trying to simplify it. One possible simplification is that we can extract the loop for finding the element in `new_columns` containing the given commit. `find_new_column_by_commit()` contains

[PATCH v3 09/13] graph: commit and post-merge lines for left-skewed merges

From: James Coglan 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 ap

[PATCH v3 04/13] graph: reduce duplication in `graph_insert_into_new_columns()`

From: James Coglan I will shortly be making some changes to this function and so am trying to simplify it. It currently contains some duplicated logic; both branches the function can take assign the commit's column index into the `mapping` array and increment `mapping_index`. Here I change the f

[PATCH v3 02/13] graph: handle line padding in `graph_next_line()`

From: James Coglan Now that the display width of graph lines is implicitly tracked via the `graph_line` interface, the calls to `graph_pad_horizontally()` no longer need to be located inside the individual output functions, where the character counting was previously being done. All the function

[PATCH v3 11/13] graph: smooth appearance of collapsing edges on commit lines

From: James Coglan 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: * |\ | * | \ *-. \ |\ \ \ | | * | | * | |

[PATCH v3 05/13] graph: remove `mapping_idx` and `graph_update_width()`

From: James Coglan There's a duplication of logic between `graph_insert_into_new_columns()` and `graph_update_width()`. `graph_insert_into_new_columns()` is called repeatedly by `graph_update_columns()` with an `int *` that tracks the offset into the `mapping` array where we should write the next

[PATCH v3 07/13] graph: example of graph output that can be simplified

From: James Coglan 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

[PATCH v3 01/13] graph: automatically track display width of graph lines

From: James Coglan All the output functions called by `graph_next_line()` currently keep track of how many printable chars they've written to the buffer, before calling `graph_pad_horizontally()` to pad the line with spaces. Some functions do this by incrementing a counter whenever they write to

[PATCH v3 06/13] graph: extract logic for moving to GRAPH_PRE_COMMIT state

From: James Coglan This computation is repeated in a couple of places and I need to add another condition to it to implement a further improvement to the graph rendering, so I'm extracting this into a function. Signed-off-by: James Coglan --- graph.c | 12 1 file changed, 8 insert

[PATCH v3 00/13] Improve the readability of log --graph output

This series of patches are designed to improve the output of the log --graph command; their effect can be summed up in the following diagram: BeforeAfter --- * |\ | * * | |\ |\ |

[PATCH v2 13/13] graph: fix coloring of octopus dashes

From: James Coglan In 04005834ed ("log: fix coloring of certain octopus merge shapes", 2018-09-01) there is a fix for the coloring of dashes following an octopus merge. It makes a distinction between the case where all parents introduce a new column, versus the case where the first parent collaps

[PATCH v2 10/13] graph: rename `new_mapping` to `old_mapping`

From: James Coglan The change I'm about to make requires being able to inspect the mapping array that was used to render the last GRAPH_COLLAPSING line while rendering a GRAPH_COMMIT line. The `new_mapping` array currently exists as a pre-allocated space for computing the next `mapping` array dur

[PATCH v2 07/13] graph: example of graph output that can be simplified

From: James Coglan 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

[PATCH v2 08/13] graph: tidy up display of left-skewed merges

From: James Coglan 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 tra

[PATCH v2 12/13] graph: flatten edges that fuse with their right neighbor

From: James Coglan 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 t

[PATCH v2 09/13] graph: commit and post-merge lines for left-skewed merges

From: James Coglan 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 ap

[PATCH v2 00/13] Improve the readability of log --graph output

This series of patches are designed to improve the output of the log --graph command; their effect can be summed up in the following diagram: BeforeAfter --- * |\ | * * | |\ |\ |

[PATCH v2 11/13] graph: smooth appearance of collapsing edges on commit lines

From: James Coglan 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: * |\ | * | \ *-. \ |\ \ \ | | * | | * | |

[PATCH v2 01/13] graph: automatically track display width of graph lines

From: James Coglan All the output functions called by `graph_next_line()` currently keep track of how many printable chars they've written to the buffer, before calling `graph_pad_horizontally()` to pad the line with spaces. Some functions do this by incrementing a counter whenever they write to

[PATCH v2 04/13] graph: reduce duplication in `graph_insert_into_new_columns()`

From: James Coglan I will shortly be making some changes to this function and so am trying to simplify it. It currently contains some duplicated logic; both branches the function can take assign the commit's column index into the `mapping` array and increment `mapping_index`. Here I change the f

[PATCH v2 05/13] graph: remove `mapping_idx` and `graph_update_width()`

From: James Coglan There's a duplication of logic between `graph_insert_into_new_columns()` and `graph_update_width()`. `graph_insert_into_new_columns()` is called repeatedly by `graph_update_columns()` with an `int *` that tracks the offset into the `mapping` array where we should write the next

[PATCH v2 06/13] graph: extract logic for moving to GRAPH_PRE_COMMIT state

From: James Coglan This computation is repeated in a couple of places and I need to add another condition to it to implement a further improvement to the graph rendering, so I'm extracting this into a function. Signed-off-by: James Coglan --- graph.c | 12 1 file changed, 8 insert

[PATCH v2 02/13] graph: handle line padding in `graph_next_line()`

From: James Coglan Now that the display width of graph lines is implicitly tracked via the `graph_line` interface, the calls to `graph_pad_horizontally()` no longer need to be located inside the individual output functions, where the character counting was previously being done. All the function

[PATCH v2 03/13] graph: reuse `find_new_column_by_commit()`

From: James Coglan I will shortly be making some changes to `graph_insert_into_new_columns()` and so am trying to simplify it. One possible simplification is that we can extract the loop for finding the element in `new_columns` containing the given commit. `find_new_column_by_commit()` contains

[PATCH 07/11] graph: commit and post-merge lines for left-skewed merges

From: James Coglan 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 ap

[PATCH 06/11] graph: tidy up display of left-skewed merges

From: James Coglan 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 veritcal pipe `|` in the GRAPH_POST_MERGE line and then immediately enter the GRAPH_COLLAPSING state. The first-parent line tra

[PATCH 10/11] graph: flatten edges that join to their right neighbor

From: James Coglan 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 t

[PATCH 08/11] graph: rename `new_mapping` to `old_mapping`

From: James Coglan The change I'm about to make requires being able to inspect the mapping array that was used to render the last GRAPH_COLLAPSING line while rendering a GRAPH_COMMIT line. The `new_mapping` array currently exists as a pre-allocated space for computing the next `mapping` array dur

[PATCH 11/11] graph: fix coloring of octopus dashes

From: James Coglan In 04005834ed ("log: fix coloring of certain octopus merge shapes", 2018-09-01) there is a fix for the coloring of dashes following an octopus merge. It makes a distinction between the case where all parents introduce a new column, versus the case where the first parent collaps

[PATCH 09/11] graph: smooth appearance of collapsing edges on commit lines

From: James Coglan 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: * |\ | * | \ *-. \ |\ \ \ | | * | | * | |

[PATCH 04/11] graph: remove `mapping_idx` and `graph_update_width()`

From: James Coglan There's a duplication of logic between `graph_insert_into_new_columns()` and `graph_update_width()`. `graph_insert_into_new_columns()` is called repeatedly by `graph_update_columns()` with an `int *` that tracks the offset into the `mapping` array where we should write the next

[PATCH 05/11] graph: extract logic for moving to GRAPH_PRE_COMMIT state

From: James Coglan This computation is repeated in a couple of places and I need to add another condition to it to implement a further improvement to the graph rendering, so I'm extracting this into a function. Signed-off-by: James Coglan --- graph.c | 12 1 file changed, 8 insert

[PATCH 03/11] graph: reduce duplication in `graph_insert_into_new_columns()`

From: James Coglan I will shortly be making some changes to this function and so am trying to simplify it. It currently contains some duplicated logic; both branches the function can take assign the commit's column index into the `mapping` array and increment `mapping_index`. Here I change the f

[PATCH 02/11] graph: reuse `find_new_column_by_commit()`

From: James Coglan I will shortly be making some changes to `graph_insert_into_new_columns()` and so am trying to simplify it. One possible simplification is that we can extract the loop for finding the element in `new_columns` containing the given commit. `find_new_column_by_commit()` contains

[PATCH 01/11] graph: automatically track visible width of `strbuf`

From: James Coglan All the output functions in `graph.c` currently keep track of how many printable chars they've written to the buffer, before calling `graph_pad_horizontally()` to pad the line with spaces. Some functions do this by incrementing a counter whenever they write to the buffer, and o

[PATCH 00/11] Improve the readability of log --graph output

This series of patches are designed to improve the output of the log --graph command; their effect can be summed up in the following diagram: BeforeAfter --- * |\ | * * | |\ |\ |