Certain Merge Commit Paths Disappear When Highlighted

[ChrisMcD1]

Describe the bug
When your cursor is over a commit that shares history with its parent via a merge commit, the graph does not show the merge out from the trunk branch into the feature branch.

To Reproduce
Steps to reproduce the behavior:

1. Open up the lazygit repo
2. Observe the graph of the commit tree
3. Go to the commits panel and move the cursor to a merge commit into master
4. Observe the graph change on the parent commit of master.

Expected behavior
I would expect the highlighting color to change, but the actual commit tree structure to stay the same.

Screenshots

Before selecting a commit (note the pink path to the right on SH's commit)

After selecting a commit (note the lack of path to the right on SH's commit)

Version info:
Building from master on commit a5698b8
git version 2.25.1

Additional context
This could be intended behavior, and if so, I'd like to bring the brief case that it shouldn't be. The feature commit did merge out of master at this point, so in the consideration of "where did this merge come from", that is a meaningful part of that story. When there is ambiguity over the parents of a commit, like this commit on recent master, it makes sense to highlight only the relevant path, but in this case there is no ambiguity.

A bit of code digging
I've also done some digging into the code and believe I have found why this behavior is happening. I've added a failing test to my fork at https://github.com/ChrisMcD1/lazygit/tree/commit-graph

A ⏣─╮
C │ ◯
B ⏣─│
D ◯ │

In this section of code it clears the cells of the selected pipes in order to redraw them with the highlight.

lazygit/pkg/gui/presentation/graph/graph.go

Lines 357 to 367 in a5698b8

	for _, pipe := range selectedPipes {
	for i := pipe.left(); i <= pipe.right(); i++ {
	cells[i].reset()
	}
	}
	for _, pipe := range selectedPipes {
	renderPipe(pipe, highlightStyle, true)
	if pipe.toPos == commitPos {
	cells[pipe.toPos].setStyle(highlightStyle)
	}

When rendering the key row in question, the row with commit B, the only selected pipe is from A -> B.

All pipes in set
Pipe: Pipe{from: 0 (A) -> to: 0 (B), kind: Terminates }
Pipe: Pipe{from: 1 (C) -> to: 0 (B), kind: Terminates }
Pipe: Pipe{from: 0 (B) -> to: 0 (D), kind: Starts }
Pipe: Pipe{from: 0 (B) -> to: 1 (F), kind: Starts }
Selected pipes
Pipe: Pipe{from: 0 (A) -> to: 0 (B), kind: Terminates }
Nonselected pipes
Pipe: Pipe{from: 1 (C) -> to: 0 (B), kind: Terminates }
Pipe: Pipe{from: 0 (B) -> to: 1 (F), kind: Starts }
Pipe: Pipe{from: 0 (B) -> to: 0 (D), kind: Starts }

Therefore, the algorithm clears cell 0 of that row, which includes the commit symbol and the arrow to the right. It then redraws only the commit symbol, because the arrow to the right is from the pipe from C -> B, which was already rendered prior.

That's as far as I got. Possible paths forward might be to consider the pipe from C -> B as selected, or to not fully clear the selected cells. But I wanted to make an issue first in case this was an intended feature.