Re: [GSoC PATCH v6 0/3] graph: add --graph-lane-limit option

[Tian Yuchen <a3205153416@gmail.com>]

On 4/2/26 00:49, Junio C Hamano wrote:
> Pablo <pabloosabaterr@gmail.com> writes:
> 
>> While working on this I spent most of the time with graph.c and
>> I got to understand well how the rendering engine works. I think
>> I have an idea about how to tackle the column rearrangement
>> like gitk, which I believe is what you thought it was about at the
>> start (and the
>> TODO that's been on graph.c for 16 years c12172d2ea).
>>
>> FWIW, I'd like to send an RFC about the column rearrangement
>> because it would be better overall, no information is lost, you can
>> still limit the number of visible columns which would replace this
>> in most cases (only scenario I can think of where you still
>> want to keep the truncation would be if you want to keep the
>> branches going straight vertically).
>>
>> I'd like to hold this series and send the RFC with the idea for the
>> rearrangement. If it ends up not being viable I would come back
>> here and add a 4th patch to remove the extra padding lines
>> (merge and collapsing lines truncated) to make it more useful
>> making the graph more compact vertically as well.
> 
> Oh, I may have found a volunteer to fix one of my pet peeves ;-)
> 
> Imagine a history with multiple root commits and you are drawing the
> history near one of the roots.  Immediately fater pacing that root
> commit, the graphing engine seems to say "ah, the next display row
> immediately below this commit '*' is vacant because it does not have
> any parent.  We can draw a commit right there" and draws a commit
> that is unrelated to that root commit it just has drawn.
> 
> Which of course makes it impossible to tell that the commit on the
> earlier row is a root, if we draw a commit immediately below it.
> We'd want to leave that column/lane open for at least one row.
> 
> Instead of
> 
>      * a child of the root commit below
>      * one of the root commits
>      * an unrelated commit X
>      * the parent of X
>      * the other root commit that is a grandparent of X
> 
> we could probably draw
> 
>      * a child of the root commit below
>      * one of the root commits
>        * an unrelated commit X
>       /
>      * the parent of X
>      * the other root commit that is a grandparent of X
> 
> or you or somebody who stared at the graph engine much longer than I
> have may have even better ideas to draw such a history.

I have some reservations about this idea, although I know little about 
the graph engine. ;)

In terms of user conventions, in --graph, '/' and '\' represent 
branching and merging respectively. Here, however, the '/' used to break 
up between different root commits is merely a placeholder and has no 
specific meaning. I feel that this not only goes against user intuition 
but also creates visual confusion: (I just drew this off the cuff, but I 
reckon it should look something like this?)

> * (main) commit 4
> | * (feature) commit 4
> | | * (doc1) commit
> | | * (doc1) root
> | |   * (main) commit 3
> | |  /| 
> | * | (feature) commit 3
> | |/
> | * (doc2) root
> |   * (main) commit 2 
> |  /
> * (feature) commit 2
> | * (main) commit 1

I don’t know about you, but I find this rather difficult to grasp. At 
the very least, I can’t tell at a glance where the actual merges and 
branches are. I don’t think a good solution should involve shifting left 
or right. Perhaps it would be better to use a special symbol in the root 
commit (such as the ■ symbol, which resembles a full stop? People would 
instinctively recognise it as a terminator):

|* (main) commit 2
| * (feature) commit 2
| ■ (doc1) ROOT COMMIT
* | (main) commit 1

(I wonder if there might be any character compatibility issues. Anyway, 
I like square characters. Square things are all rather cute.)

Regards, Yuchen