From: Toon Claes <toon@iotcl.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH RFC] graph: implement git-log(1) --untangle
Date: Mon, 09 Feb 2026 07:38:21 +0100 [thread overview]
Message-ID: <87h5rqqv4y.fsf@iotcl.com> (raw)
In-Reply-To: <ad776ca0-1038-43f7-860d-2f3a78a5db6d@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> IMNSHO, we need a better way to show where links to parents were
> truncated. Otherwise, I must consider this chart an incorrect
> representation of the history above.
The only alternative I can come up is showing as if the branch was made
from the parent commit of the merge commit. Like so:
Real:
*
|\
| *
| *
* \
|\ |
* * |
|/ /
* /
*
My current implementation:
*
|\
| *
| *
*
|\
* *
|/
*
*
The suggestion:
*
|\
| *
| *
|/
*
|\
* *
|/
*
*
But either way, what it shown it wrong. And that's in my opinion a
tradeoff of this feature.
I've been thinking about something else. Display in some way part of the
history is missing, maybe by showing a '.' in the graph:
*
|\
| *
| *
| .
*
|\
* *
|/
*
*
This indicates a piece of the history is truncated. I'm still on the
fence about this
>
>> As you can see, this untangles the arms of the octopus.
>
> This example is too small to show any real improvement. But I think I
> understood what the goal is.
I would like to invite anyone here to try the feature on some of your
repositories you have. I feel it's impossible to really demonstrate it's
power through some examples over email.
> So, the option's effect is to untangle visual representation of the
> history. It is achieved by truncating links between merge-bases and
> commits that appear in non-first parent links.
Yes, that's the idea.
> How does this work with criss-cross merges?
>
> Z
> / \
> o o
> |\ /|
> | x |
> |/ \|
> o o
> \ /
> A
I haven't tried it yet.
>
> (not sure how --graph would represent this...)
>
> How does this work with backward merges?
>
> * main
> |\
> * | C
> | * sync with main
> |/|
> * | B
> | * A
> |/
> * initial
I've been trying in this first version to address that, but I haven't
been fully able to make it work.
I assume you and other readers know, but your example is a
simplification of:
* main
|\
* | C
| * sync with main
| |\
| |/
|/|
* | B
| * A
|/
* initial
So here there merge-base isn't the first parent, so things get a little
more complicated. Also when 'B' is ignored as merge-base, the merge-base
needs to be recalculated to be 'initial'.
Anyhow, the idea is to show it like this:
* main
|\
* | C
| * sync with main
* | B
| * A
* initial
If you don't like my proposal of being fully disconnected from the
merge-base, we could consider using a different symbol for "truncated"
history:
* main
|\
* | C
| + sync with main
* | B
| + A
* initial
The commits with a '+' have more parents but they are not shown.
> How does this interact with --boundary?
Haven't tried it yet.
> Speaking of which, boundary commits are listed last. Since they need to
> be linked to the commits for which they are the boundary, a whole lot of
> these "unnecessary" lines accumulate the longer the list of commits is.
That's good to know, when I continue work on this feature.
> If only there were a way to show boundary commits as soon as possible,
> then this accumulation would not happen.
I'll need to dive deeper into this to understand what you're saying
here.
--
Cheers,
Toon
next prev parent reply other threads:[~2026-02-09 6:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 18:49 [PATCH RFC] graph: implement git-log(1) --untangle Toon Claes
2026-02-06 21:27 ` Junio C Hamano
2026-02-09 6:19 ` Toon Claes
2026-02-07 9:32 ` Johannes Sixt
2026-02-09 6:38 ` Toon Claes [this message]
2026-02-09 16:39 ` Johannes Sixt
2026-02-09 19:35 ` 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=87h5rqqv4y.fsf@iotcl.com \
--to=toon@iotcl.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.