Re: [PATCH v8 4/4] graph: indent visual root in graph

[Mirko Faina <mroik@delayed.space>]

On Fri, Jul 10, 2026 at 12:37:07PM +0200, Pablo Sabater wrote:
> When rendering a graph, if the history contains multiple "visual roots",
> actual roots or commits that look like roots (i.e. have their parents
> filtered out) can end up being vertically adjacent to unrelated commits,
> falsely appearing to be related.
> 
> A fix for this issue was already attempted [1] a while ago.
> 
> This happens because the commits fill the space from left to right and
> when a visual root ends, its column becomes free for the following
> commit even if they are not related. Once this happens the unrelated
> commit is rendered below the visual root. Because there is no special
> character or way to identify when a visual root is rendered making the
> graph confusing.
> 
> By indenting the visual roots when there are still commits to show the
> vertical adjacency can be avoided.
> 
> Add is_visual_root flag to git_graph making it visible in all graph states,
> give graph_update() a new function, graph_is_visual_root() to know if the
> current commit is a visual root and set is_visual_root.
> The different handled cases are:
> 
> - If a visual root has children: similar to GRAPH_PRE_COMMIT state when
>   octopus merges need space, an edge row needs to be printed to connect
>   the child with the indented visual root. A new state GRAPH_PRE_ROOT is
>   needed to connect the child with the visual root:
> 
>     * child of the visual root
>      \ GRAPH_PRE_ROOT
>       * visual root indented
> 
> - If a visual root is child-less we can skip GRAPH_PRE_ROOT state and
>   render the indented commit directly.
> 
>       * visual root indented
>     * unrelated commit
> 
> - If two or more visual roots are adjacent: by having a lookahead to the
>   next commit that will be rendered, if the next commit is also a visual
>   root and we are on a visual root, meaning two visual root adjacent in
>   the history, the top one can omit the indent, making the one below to
>   indent only once, if there are more adjacent visual commits, the
>   indentation will increase for each adjacent one, cascading.
> 
>     * visual root
>       * visual root
>         * visual root
>     * last commit
> 
>   Even if the last commit is a root, because there is nothing that will be
>   rendered below we can omit the indentation on purpose.
> 
> [1]: https://lore.kernel.org/git/xmqqwnwajbuj.fsf@gitster.c.googlers.com/
> 
> Helped-by: Kristofer Karlsson <krka@spotify.com>
> Mentored-by: Karthik Nayak <karthik.188@gmail.com>
> Mentored-by: Chandra Pratap <chandrapratap3519@gmail.com>
> Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com>
> ---
>  graph.c                          | 235 +++++++++++++++++++
>  t/meson.build                    |   1 +
>  t/t4218-log-graph-indentation.sh | 473 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 709 insertions(+)

This doesn't seem to work for every visual root e.g.

    git log --graph --oneline --author="Mirko Faina"

The visual roots are not indented.

> +/*
> + * A commit can be a visual root when:
> + *
> + * - It has no parents.
> + *
> + * - It has parents but they are all filtered out and
> + *   commit->parents arrives NULL.
> + *
> + * - It is not a boundary commit. Boundary commits also have no visible
> + *   parents, but they are not selected as visual roots because they cannot
> + *   cause the ambiguity of being vertically adjacent because:
> + *
> + *   1. A boundary only appears because an included commit is its child.
> + *      Children are always above, and the renderer draws an edge down to
> + *      the boundary from that child. Rather than starting a column like a
> + *      visual root would do, it inherits its child column.
> + *
> + *   2. Included commits cannot appear below a boundary. Boundaries are
> + *      ancestors of the exclusion point; if an included commit were an
> + *      ancestor of the boundary it would be excluded and not rendered.
> + *      Boundaries therefore always sink to the bottom.
> + */
> +static int graph_is_visual_root_candidate(struct commit *c)
> +{
> +	return c->parents == NULL && !(c->object.flags & BOUNDARY);
> +}

I suspect this behaviour is due to these assumptions being too strict.

When we use the --author option the parents are not filtered out, so it
doesn't return NULL desipte being a visual root. We realize it is a
visual root only on the next commit, but once we are on the next commit
we can't indent as we have already printed this commit.

We realize only on the next commit after hitting simplify_commit(), it
calls get_commit_action() and checks if should keep the commit based on
the regex we provided. If the regex is not matched the commit is just
ignored (we do not filter parents based on regex when we expand a topo
walk).

At least that's what I gather, if anyone can confirm this...