Thread (92 messages) 92 messages, 7 authors, 37m ago

Re: [PATCH v9 0/4] graph: indent visual roots in graph

From: Chandra Pratap <hidden>
Date: 2026-07-12 05:56:56

On Sat, 11 Jul 2026 at 21:55, Mirko Faina [off-list ref] wrote:
On Sat, Jul 11, 2026 at 05:41:58PM +0200, Pablo Sabater wrote:
quoted
I think that this solves an ambiguity so it should be the default option
and someone who doesn't want the indentation has to explicitly unset it
maybe with something like '--no-graph-indent'.
The reason I prefer the current way of printing as the default is
because the ambiguity arises only when each commit occupies exactly one
line. In any other case we can clearly see the edges connecting the
vertices. I'd rather have --oneline imply what would be --graph-indent
instead of having to pass --no-graph-indent on any other format
different from --oneline or --format=reference.
Tying graph-drawing logic to specific formatting flags could introduce
inconsistencies. For example, if a user relies on a custom format like
--format="%h %s", the output is functionally single-line and suffers
from the exact same ambiguity, but it would miss the fix.

Even in multi-line formats, relying on the absence of a '|' character to spot
unrelated commits requires active effort. Indentation provides an immediate
visual cue that breaks the vertical lineage, which is helpful regardless of the
commit message length.

I agree with Pablo: for users who strictly want the old behavior, an opt-out
flag keeps the graph logic decoupled from the formatting logic.
quoted
Apart from having an option to disable indentation.

We could have the cascading to have a limit or make it zig-zag:

instead of:

A
  B
    C
      D

We could do:

A
  B
C
  D

This would have its own edge cases like:

A
  B
C <- if we zig-zag here C and D become ambiguous, currently we are
D    indenting only the last commits (visual roots) here we would have
D    to chose between continuing cascading or indenting the first of D.

I'm not so sure if I like the zig-zag solution because we need to think again
if it causes an ambiguity, but I wanted to mention it.

I think we need some more opinions about the design.
I don't dislike the the current solution but I can see it degenerating
if someone contributes a lot of one-patch series.

Maybe you could indent commits that are both head and tail up to two
levels and then on the third go back to the beginning of the line. That
way you kind of have a zig-zag but without ambiguity. You'd only have to
add a counter to keep track of the level of indentation.
Not sure about this. A zig-zag pattern visually mimics branching and
merging, which makes unrelated commits look like a complex merge topology.

I also have a feeling that this will end up recreating the exact ambiguity this
patch series is trying to fix.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help