Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Pablo <pabloosabaterr@gmail.com>
Cc: Johannes Sixt <j6t@kdbg.org>,
	 christian.couder@gmail.com, karthik.188@gmail.com,
	 jltobler@gmail.com,  ayu.chandekar@gmail.com,
	siddharthasthana31@gmail.com,  chandrapratap3519@gmail.com,
	szeder.dev@gmail.com,  git@vger.kernel.org
Subject: Re: [GSoC PATCH v6 0/3] graph: add --graph-lane-limit option
Date: Wed, 01 Apr 2026 09:49:46 -0700	[thread overview]
Message-ID: <xmqqikaawrpx.fsf@gitster.g> (raw)
In-Reply-To: <CAN5EUNR_yfkv_hC4wg-nHNg=3FnkYdvFm6FcOUNG2A=MdGs7ZQ@mail.gmail.com> (Pablo's message of "Wed, 1 Apr 2026 16:42:26 +0200")

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.

  reply	other threads:[~2026-04-01 16:49 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-16 13:34 [GSoC RFC PATCH] graph: add --graph-max option to limit displayed columns Pablo Sabater
2026-03-16 17:04 ` Karthik Nayak
2026-03-16 19:48   ` Pablo
2026-03-17 22:09 ` [GSoC RFC PATCH v2] graph: add --max-columns " Pablo Sabater
2026-03-18 16:05   ` Junio C Hamano
2026-03-18 18:20     ` Pablo
2026-03-19  7:07       ` Johannes Sixt
2026-03-22 19:54   ` [GSoC PATCH WIP RFC v3 0/3] graph: add --graph-lane-limit option Pablo Sabater
2026-03-22 20:37     ` [GSoC PATCH WIP RFC v3 1/3] " Pablo Sabater
2026-03-22 20:38       ` [GSoC PATCH WIP RFC v3 2/3] graph: truncate graph visual output Pablo Sabater
2026-03-22 20:38       ` [GSoC PATCH WIP RFC v3 3/3] graph: add documentation and testing about --graph-lane-limit Pablo Sabater
2026-03-22 22:09       ` [GSoC PATCH WIP RFC v3 1/3] graph: add --graph-lane-limit option Junio C Hamano
2026-03-23  2:33         ` Pablo
2026-03-23 21:59     ` [GSoC PATCH v4 0/3] " Pablo Sabater
2026-03-23 21:59       ` [GSoC PATCH v4 1/3] " Pablo Sabater
2026-03-25  7:02         ` SZEDER Gábor
2026-03-25 10:03         ` Johannes Sixt
2026-03-25 12:29           ` Pablo
2026-03-23 21:59       ` [GSoC PATCH v4 2/3] graph: truncate graph visual output Pablo Sabater
2026-03-25 10:04         ` Johannes Sixt
2026-03-25 11:19           ` Pablo
2026-03-23 21:59       ` [GSoC PATCH v4 3/3] graph: add documentation and tests about --graph-lane-limit Pablo Sabater
2026-03-25 10:07         ` Johannes Sixt
2026-03-25 11:49           ` Pablo
2026-03-25 10:02       ` [GSoC PATCH v4 0/3] graph: add --graph-lane-limit option Johannes Sixt
2026-03-25 12:28         ` Pablo
2026-03-25 17:44           ` Johannes Sixt
2026-03-25 17:58             ` Pablo
2026-03-25 17:43       ` [GSoC PATCH v5 0/2] " Pablo Sabater
2026-03-25 17:44         ` [GSoC PATCH v5 1/2] " Pablo Sabater
2026-03-25 22:11           ` Junio C Hamano
2026-03-27 14:22             ` Pablo
2026-03-27 16:07               ` Pablo
2026-03-27 16:34               ` Junio C Hamano
2026-03-25 17:44         ` [GSoC PATCH v5 2/2] graph: add documentation and tests about --graph-lane-limit Pablo Sabater
2026-03-28  0:11         ` [GSoC PATCH v6 0/3] graph: add --graph-lane-limit option Pablo Sabater
2026-03-28  0:11           ` [GSoC PATCH v6 1/3] graph: limit the graph width to a hard-coded max Pablo Sabater
2026-03-28  0:11           ` [GSoC PATCH v6 2/3] graph: add --graph-lane-limit option Pablo Sabater
2026-03-28  0:11           ` [GSoC PATCH v6 3/3] graph: add truncation mark to capped lanes Pablo Sabater
2026-03-31 22:14           ` [GSoC PATCH v6 0/3] graph: add --graph-lane-limit option Junio C Hamano
2026-04-01  8:36           ` Johannes Sixt
2026-04-01 14:42             ` Pablo
2026-04-01 16:49               ` Junio C Hamano [this message]
2026-04-02  5:53                 ` Pablo
2026-04-02 19:55                   ` Junio C Hamano
2026-04-03 18:56                 ` Tian Yuchen
2026-04-03 19:13                   ` Pablo
2026-04-03 20:15                   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqikaawrpx.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ayu.chandekar@gmail.com \
    --cc=chandrapratap3519@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=jltobler@gmail.com \
    --cc=karthik.188@gmail.com \
    --cc=pabloosabaterr@gmail.com \
    --cc=siddharthasthana31@gmail.com \
    --cc=szeder.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox