From: Pablo Sabater <pabloosabaterr@gmail.com>
To: 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, j6t@kdbg.org, szeder.dev@gmail.com,
Pablo Sabater <pabloosabaterr@gmail.com>
Subject: [GSoC PATCH v5 0/2] graph: add --graph-lane-limit option
Date: Wed, 25 Mar 2026 18:43:59 +0100 [thread overview]
Message-ID: <20260325174401.217577-1-pabloosabaterr@gmail.com> (raw)
In-Reply-To: <20260323215935.74486-1-pabloosabaterr@gmail.com>
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
The '~' is the truncation mark, not an actual lane. It was chosen because '.' is
already used in octopus merges and '~' is not used elsewhere in the graph. Yet
the edges between the last visible lane and the truncation mark are still
conserved.
The '*' commit mark is visible when it lives on a visible lane or the first
hidden lane, any deeper lane doesn't show the commit mark but keeps the commit
message visible.
Merges where neither the commit nor its parents live on a visible lane are skipped
because they don't carry any visible information.
The original idea to limit columns was noted as a TODO in c12172d2ea
(Add history graph API, 2008-05-04). This does not implement
gitk-style column rearrangement, it only truncates the visual output.
Possible future improvements:
- When all branches involved in collapsing or padding are over the limit, the
truncated lane doesn't show any information, this lane could be removed to
make the graph more compact. Currently these lanes still appear because
graph_output_collapsing_line() mixes state handling with rendering, so it can't
be skipped but callers always expect a non empty buffer. Fixing it would need
to refactor the callers to handle empty buffers instead of expecting them to
always have content.
- Collapsing and merges lanes that start on visible lanes but end on hidden ones
are kept to maintain the most information possible on the visible lanes, but
the information about where they go is lost. They can be kept, removed or think
of a way to show that information without showing the lanes.
Changes since v4:
- Merged the option parsing and the truncation logic into a single
patch, fixing the DEVELOPER=1 build break when the first patch was alone.
- Added before/after example to clarify horizontal truncation.
- Fixed error message to match existing format strings.
- Shortened code comment.
- Changed truncation_max -= 1 to truncation_max--.
- Fixed pre-existing indentation in graph_output_collapsing_line().
- Fixed unnecessary blank line changes.
- Added that zero and negative values mean no limit in the docs.
- Changed truncation mark from '.' to '~' because '.' is already
used in octopus merges.
- Added more tests.
Pablo Sabater (2):
graph: add --graph-lane-limit option
graph: add documentation and tests about --graph-lane-limit
Documentation/rev-list-options.adoc | 6 ++
graph.c | 149 +++++++++++++++++++++++-----
revision.c | 6 ++
revision.h | 1 +
t/t4215-log-skewed-merges.sh | 144 +++++++++++++++++++++++++++
5 files changed, 283 insertions(+), 23 deletions(-)
base-commit: ce74208c2fa13943fffa58f168ac27a76d0eb789
--
2.43.0
next prev parent reply other threads:[~2026-03-25 17:44 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
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 ` Pablo Sabater [this message]
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=20260325174401.217577-1-pabloosabaterr@gmail.com \
--to=pabloosabaterr@gmail.com \
--cc=ayu.chandekar@gmail.com \
--cc=chandrapratap3519@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=jltobler@gmail.com \
--cc=karthik.188@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