[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`

[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 fi

[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

[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

[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

[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 chang

[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

[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 writ

[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

[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 wri

[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 chang

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

eft and the new rendering on the right. A final addition to that set of changes fixes the coloring of dashes that are drawn next to octopus merges, in a manner compatible with all these changes. The early commits in this set are refactorings that make the functional changes easier to introduce. J

[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 fi

[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`

[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

[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

[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

[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

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

eft and the new rendering on the right. A final addition to that set of changes fixes the coloring of dashes that are drawn next to octopus merges, in a manner compatible with all these changes. The early commits in this set are refactorings that make the functional changes easier to introduce. J

[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 wri

[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 chang

[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 writ

[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 chang

[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

[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

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

On 13/10/2019 08:15, Jeff King wrote: > On Thu, Oct 10, 2019 at 09:13:42AM -0700, James Coglan via GitGitGadget wrote: > >> A final addition to that set of changes fixes the coloring of dashes that >> are drawn next to octopus merges, in a manner compatible with all these >

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

On 13/10/2019 07:56, Jeff King wrote: > On Fri, Oct 11, 2019 at 06:04:21PM +0100, James Coglan wrote: > >>> 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 <<-EO

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

On 12/10/2019 02:36, Derrick Stolee wrote: > On 10/11/2019 12:50 PM, James Coglan wrote: >> On 10/10/2019 18:19, Derrick Stolee wrote: >>> On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote: >>>> +++ b/t/t4215-log-skewed-merges.sh >>

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

On 14/10/2019 13:55, James Coglan wrote: > Thanks! For completeness, here is the current state of this patch after I've > been through the feedback up to this point: > > From 241180570fbaae04a2263c5ff1ab3b92f54f8004 Mon Sep 17 00:00:00 2001 > From: James Coglan > Date: Th

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

On 12/10/2019 01:27, Junio C Hamano wrote: > James Coglan writes: > >> - We don't want a general solution to this problem for everything >> `strbuf` could be used for; it only needs to address the graph >> padding problem. > > Of course. Somebody may use str

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

On 11/10/2019 17:02, Johannes Schindelin wrote: > Hi, > > On Thu, 10 Oct 2019, Denton Liu wrote: > >> On Fri, Oct 11, 2019 at 10:42:20AM +0900, Junio C Hamano wrote: >>> Denton Liu writes: >>> static int calculate_width(const struct strbuf *row) { int in_termcode

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

Hi Johannes, On 10/10/2019 22:07, Johannes Schindelin wrote: > Hi James, > > On Thu, 10 Oct 2019, James Coglan via GitGitGadget wrote: > >> From: James Coglan >> >> All the output functions in `graph.c` currently keep track of how many >> printable chars t

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

On 10/10/2019 18:49, Derrick Stolee wrote: > On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote: >> From: James Coglan >> >> Following the introduction of "left-skewed" merges, which are merges >> whose first parent fuses with another edge to its lef

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

On 10/10/2019 18:19, Derrick Stolee wrote: > On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote: >> +++ b/t/t4215-log-skewed-merges.sh >> @@ -0,0 +1,42 @@ >> +#!/bin/sh >> + >> +test_description='git log --graph of skewed merges' >> +

[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

[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

[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

[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`

[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 fi

[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 writ

[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 chang

[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 chang

[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

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

eft and the new rendering on the right. A final addition to that set of changes fixes the coloring of dashes that are drawn next to octopus merges, in a manner compatible with all these changes. The early commits in this set are refactorings that make the functional changes easier to introduce. J