public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg•org>
To: Pablo Sabater <pabloosabaterr@gmail•com>, git@vger•kernel.org
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
Subject: Re: [GSoC PATCH v4 3/3] graph: add documentation and tests about --graph-lane-limit
Date: Wed, 25 Mar 2026 11:07:06 +0100	[thread overview]
Message-ID: <6cdcece0-8cc5-4c87-8727-6d3e17424a9e@kdbg.org> (raw)
In-Reply-To: <20260323215935.74486-4-pabloosabaterr@gmail.com>

Am 23.03.26 um 22:59 schrieb Pablo Sabater:
> @@ -1259,6 +1259,11 @@ This implies the `--topo-order` option by default, but the
>  	in between them in that case. If _<barrier>_ is specified, it
>  	is the string that will be shown instead of the default one.
>  
> +`--graph-lane-limit=<n>`::
> +	When `--graph` is used, limit the number of graph lanes to be shown.
> +	Lanes over the limit are replaced with a truncation mark '.'. By default
> +	there is no limit.

This should probably mention that 0 means no limit.

> +
>  ifdef::git-rev-list[]
>  `--count`::
>  	Print a number stating how many commits would have been
> diff --git a/t/t4215-log-skewed-merges.sh b/t/t4215-log-skewed-merges.sh
> index 28d0779a8c..650701df42 100755
> --- a/t/t4215-log-skewed-merges.sh
> +++ b/t/t4215-log-skewed-merges.sh
> @@ -370,4 +370,57 @@ test_expect_success 'log --graph with multiple tips' '
>  	EOF
>  '
>  
> +test_expect_success 'log --graph --graph-lane-limit=2 limited to two lanes' '
> +	check_graph --graph-lane-limit=2 M_7 <<-\EOF
> +	*-.   7_M4
> +	|\ \
> +	| | * 7_G
> +	| | * 7_F
> +	| * . 7_E
> +	| * . 7_D
> +	* | . 7_C
> +	| |/
> +	|/|
> +	* | 7_B
> +	|/
> +	* 7_A

I'm confused. If the lane limit is 2, why do we have actually have 3 lanes?

> +test_expect_success 'log --graph --graph-lane-limit=3 limited to three lanes' '
> +	check_graph --graph-lane-limit=3 M_1 M_3 M_5 M_7 <<-\EOF
> +	*   7_M1
> +	|\
> +	| | *   7_M2
> +	| | |\
> +	| | | * 7_H
> +	| | | . 7_M3
> +	| | | . 7_J
> +	| | | . 7_I
> +	| | | . 7_M4
> +	| |_|_.
> +	|/| | .
> +	| | |_.
> +	| |/| .
> +	| | | .
> +	| | |/.
> +	| | * . 7_G
> +	| | | .
> +	| | |/.
> +	| | * . 7_F
> +	| * | . 7_E
> +	| | |/.
> +	| |/| .
> +	| * | . 7_D
> +	| | |/
> +	| |/|
> +	* | | 7_C
> +	| |/
> +	|/|
> +	* | 7_B
> +	|/
> +	* 7_A

Same here. Why is there a fourth lane?

Oh! "Truncation" here does not mean that the vertial lines are cut off
and are supposed to continue sometime later in the chart. It literally
means that the *line* is truncated and just some stuff *on that line* is
omitted.

Ouch! That was not what I was expecting. I thought that truncation means
that when the eye follows a line vertically, it finds the truncation
point of the line at some point, and then the continuation of that line
is again some time later down the chart. The only clue which lanes are
the same would be the color, which would have to be remedied somehow.

I don't know what to make of it. I have to reconsider.

-- Hannes


  reply	other threads:[~2026-03-25 10:07 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 [this message]
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
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=6cdcece0-8cc5-4c87-8727-6d3e17424a9e@kdbg.org \
    --to=j6t@kdbg$(echo .)org \
    --cc=ayu.chandekar@gmail$(echo .)com \
    --cc=chandrapratap3519@gmail$(echo .)com \
    --cc=christian.couder@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    --cc=jltobler@gmail$(echo .)com \
    --cc=karthik.188@gmail$(echo .)com \
    --cc=pabloosabaterr@gmail$(echo .)com \
    --cc=siddharthasthana31@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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