public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Pablo Sabater <pabloosabaterr@gmail.com>
Cc: git@vger.kernel.org,  christian.couder@gmail.com,
	karthik.188@gmail.com,  jltobler@gmail.com,
	 ayu.chandekar@gmail.com, siddharthasthana31@gmail.com,
	 chandrapratap3519@gmail.com
Subject: Re: [GSoC RFC PATCH v2] graph: add --max-columns option to limit displayed columns
Date: Wed, 18 Mar 2026 09:05:17 -0700	[thread overview]
Message-ID: <xmqqzf45gm2q.fsf@gitster.g> (raw)
In-Reply-To: <20260317220929.120746-1-pabloosabaterr@gmail.com> (Pablo Sabater's message of "Tue, 17 Mar 2026 23:09:29 +0100")

Pablo Sabater <pabloosabaterr@gmail.com> writes:

> Repositories that have many active branches produce very wide
> outputs with 'git log --graph --all', makes it difficult to read.

"making it difficult"?

> Add '--max-columns=<n>' to limit the columns shown. Columns over
> the limit are replaced with a '.' truncation indicator. This only
> affects the visual rendering.

Being an option to "git log", I expect that readers would naturally
take "--max-columns=<n>" to refer to the total display width
consumed by the entire output including the log messages and
possibly patches when the command is run with the "-p" option,
whether the ancestry graph is shown or not.

But somehow I suspect that it is not what is going on here.

If this <n> refers to the width of graph part only, the option name
should hint that fact somehow.  Perhaps include the word "graph" in
it, or something.  As you use the verb "limit" below, perhaps
"--limit-graph-columns=<n>"?

> The commit mark '*' is only shown in two cases:
> - The commit is in a branch inside the limit.
> - The commit is in the first hidden branch, in this case '.'
>   is replaced by '*'.

> Commits on deeper hidden branches do not show '*' but the commit
> subject is still shown, so no information is lost.

Isn't "no information is lost" a huge exaggeration?  We are losing
the ancestry information by not drawing graph lines, aren't we?

> The original idea to limit columns was noted as a TODO in
> c12172d2ea (Add history graph API, 2008-05-04), which mentions
> gitk's behavior. This does not implement gitk-style column
> rearrangement; it only truncates the visual output.

True.  

IIRC, Gitk also allows you to click the chopped arrow-head to jump
to the other end of the omitted ancestry line, which is very useful
but is hard to do on a terminal output that is not interactive.

> git log --graph --all --oneline --max-columns=2
> *   b81d099 (M_1) 7_M1
> |\
> | | * 2d96ba0 (M_3) 7_M2
> | | .

I would call this output consuming 5 columns for graph part, not 2.
For end users, being able to specify 2, i.e., being able to say "I
tolerate wasting display columns to show up to two ancestry lines"
(or "two lanes of ancestry information"), is indeed a lot more
intuitive than having to say "You are allowed to use up to 5 display
columns", so I do not object to an option that takes "2" as its
value and produces the above output, but I am not sure if we want to
have "columns" in the name of such an option; "--limit-graph-lanes=2"?

> - I think --max-columns is a good name, but it does not have --graph
>   prefix, bcs it can only be on --graph I think it's clear enough.

If "git log --max-columns=77" ignores the option because "--graph"
is not given, it would be confusing to the users.

> +	/*
> +	 * If graph_max_columns is set, cap the padding from the branches
> +	 */
> +	if (graph->revs->graph_max_columns > 0) {
> +		int truncation = graph->revs->graph_max_columns * 2 + 2;

This needs a bit more commenting to explain where these magic
numbers come from; they are of the same value 2 but have different
meanings, right?  Like this (only to illustrate the shape, not
suggesting what the contents should read):

		/*
		 * Each ancestry "lane" occupies 2 columns, and
		 * we leave two columns before drawing the commit
		 * title and log message part.
		 */
		int max_column_width = 
			graph->revs->graph_limit_lanes * 2 + 2;

> +
> +	if (revs->graph_max_columns > 0 && !revs->graph)
> +		die(_("option '%s' requires '%s'"), "--max-columns", "--graph");

The naming is so selfish.  Among "git log" options that exists and
that will be added in the future, this design decision declares that
"--graph" is and will remain to be the only one that may want to
specify the maximum number of columns to spend.

If the option is named clearly to be related to the "--graph"
feature, another way to go is to make it imply "--graph".  If the
user says "I want to limit the graph output to consume no more than
10 leftmost columns", it is clear that the user expects the graph to
be shown.

  reply	other threads:[~2026-03-18 16:05 UTC|newest]

Thread overview: 39+ 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 [this message]
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

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=xmqqzf45gm2q.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=jltobler@gmail.com \
    --cc=karthik.188@gmail.com \
    --cc=pabloosabaterr@gmail.com \
    --cc=siddharthasthana31@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