Re: [PATCH RFC] graph: implement git-log(1) --untangle

From: Johannes Sixt <j6t@kdbg.org>
Date: Feb 7, 2026, 09:32 UTC
Message-ID: <ad776ca0-1038-43f7-860d-2f3a78a5db6d@kdbg.org>
In-Reply-To: <20260206-toon-log-graph-no-merge-base-v1-1-a6f983991a1d@iotcl.com>

Am 06.02.26 um 19:49 schrieb Toon Claes:

Show 31 quoted lines

> The output of `git log --graph` can be cluttered when dealing with
> long-living branches or octopus merges.
> 
> For example consider this graph:
> 
>     * left
>     | *-.   octopus-merge
>     |/|\ \
>     | | | * 4
>     | | * | 3
>     | | |/
>     | * / 2
>     | |/
>     * / 1
>     |/
>     * initial
> 
> The reason this looks messy, is because for each merged branch there is
> a line back to the source branch. But in most cases, the user doesn't
> care when merged branches are branched of.
> 
> To simplify the graph, implement option `--untangle`.
> 
>     * left
>     | *-.   octopus-merge
>     |/|\ \
>     | | | * 4
>     | | * 3
>     | * 2
>     * 1
>     * initial

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.

> 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.

Show 5 quoted lines

> To implement this feature, merge commits are treated a differently. For
> each parent commit (except the first one) of a merge, the merge-base
> with the first parent is found. That merge-base is saved in the column
> for that branch and when the next commit for the column would be that
> merge-base, no lines are drawn no more.

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.

How does this work with criss-cross merges?

  Z
 / \
o   o
|\ /|
| x |
|/ \|
o   o
 \ /
  A

(not sure how --graph would represent this...)

How does this work with backward merges?

* main
|\
* | C
| * sync with main
|/|
* | B
| * A
|/
* initial

How does this interact with --boundary?

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. If only there were a way to show boundary commits as soon as possible, then this accumulation would not happen.

-- Hannes