public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox