Git development
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Pablo Sabater <pabloosabaterr@gmail.com>
Cc: christian.couder@gmail.com, karthik.188@gmail.com,
	jltobler@gmail.com, ayu.chandekar@gmail.com,
	siddharthasthana31@gmail.com, chandrapratap3519@gmail.com,
	gitster@pobox.com, szeder.dev@gmail.com, git@vger.kernel.org
Subject: Re: [GSoC PATCH v6 0/3] graph: add --graph-lane-limit option
Date: Wed, 1 Apr 2026 10:36:18 +0200	[thread overview]
Message-ID: <bdff0a5d-b738-4053-9b72-08eba88156de@kdbg.org> (raw)
In-Reply-To: <20260328001113.1275291-1-pabloosabaterr@gmail.com>

Am 28.03.26 um 01:11 schrieb Pablo Sabater:
> Repositories that have many active branches at the same time produce
> wide graphs. A lane consists of two columns, the edge and the space
> padding, each branch takes a lane in the graph and there is no way
> to limit how many can be shown.
> 
> The limit is a horizontal truncation, each lane is cut at the lane limit:
> 
>   Without --graph-lane-limit:
> 
>   *   7_M1
>   |\  
>   | * 7_E
>   * | 7_C
>   | | *   7_M2
>   | | |\  
>   | | | * 7_H
>   | | |/  
>   | |/|   
>   | * | 7_D
>   | | * 7_G
>   | | * 7_F
>   | |/  
>   |/|   
>   * | 7_B
>   |/  
>   * 7_A
> 
>   With --graph-lane-limit=1:
> 
>   *   7_M1
>   |\  
>   | * 7_E
>   * ~ 7_C
>   | ~ 7_M2
>   | ~ 7_H
>   | ~ 
>   | ~ 
>   | * 7_D
>   | ~ 7_G
>   | ~ 7_F
>   | ~ 
>   |/~ 
>   * ~ 7_B
>   |/  
>   * 7_A

After seeing this example, my first reaction was that this
--graph-lane-limit option would not be useful for me. The relationship
among the commits is apparently obfuscated to such a degree that the
graph is not a lot better than a plain listing without --graph.

But then I tried on a few real-world examples, and the result turned out
to be a lot better. The commits (asterisks) typically occur in the
left-most lanes, and the lanes to the right are usually just connections
without commits. This makes it more practical to just truncate the graph
part, i.e., hide the connecting lanes.

In conclusion, I regard the way the option works as useful, even though
it is not the way of truncation I had envisioned originally.

I discovered a small glitch, though. If you download today's gitk
repository https://github.com/j6t/gitk.git, run

  git log --graph --oneline --decorate --boundary \
     --graph-lane-limit=4 465f03869ae11acd0..origin/j6t-testing

(j6t-testing is a volatile branch and is 86848fe40b60ae58f today).
Scroll down to line 166 and you see the '~' at the wrong place:

| | * | ~ 9f0d1c2 gitk: sanitize 'exec' arguments: simple cases
| | * | ~ 6eb797f gitk: have callers of diffcmd supply pipe symbol...
| | * | ~ b966b73 gitk: treat file names beginning with "|" as...
* | | | ~ 0c8be6f Merge branch 'ah/fix-open-with-stdin'
|\| | |~           <-- this is line 166
| * | | ~ 8e3070a (...) gitk: encode arguments correctly with "open"
* | | | ~ bfb0fa7 Merge branch 'top-panel-search-highlight' of ...
|\ \ \ \~
| * | | ~ 9cad4a9 gitk: do not hard-code color of search results...

I haven't tried to find out what is going wrong here or to simplify the
reproducer.

-- Hannes


  parent reply	other threads:[~2026-04-01  8:36 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 [this message]
2026-04-01 14:42             ` Pablo
2026-04-01 16:49               ` Junio C Hamano
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=bdff0a5d-b738-4053-9b72-08eba88156de@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=ayu.chandekar@gmail.com \
    --cc=chandrapratap3519@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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