From: Johannes Sixt Date: Sat, 07 Feb 2026 09:32:25 GMT Subject: Re: [PATCH RFC] graph: implement git-log(1) --untangle Message-ID: 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: > 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. > 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