Fix real branches drawn as virtual

[antons]

This PR fixes a long-standing bug where real branches (thick solid lines) are drawn as virtual (thin dashed lines) when their tip is a part of another, newer branch. The fix splits branch line drawing into two segments, dashed and solid.

Before:

After:

I AGREE TO THE GITUP CONTRIBUTOR LICENSE AGREEMENT

[greptile-apps]

Greptile Summary

This PR changes virtual branch rendering so only the dummy prefix remains thin and dashed while the real branch portion becomes solid and receives the appropriate width. It also marks the transition node and adds geometry helpers for splitting line and quadratic path segments.

• Finds the first real node in a virtual line.
• Splits virtual line paths at that node into dashed and solid paths.
• Draws a node marker where the virtual prefix terminates.

Confidence Score: 4/5

The curved transition should be corrected before merging because it still renders part of the real branch as dashed when the virtual line changes columns at its first real node.

The new split correctly handles straight segments and most of the virtual-to-real transition, but a quadratic corner ending on the boundary is assigned wholly to the dashed path despite extending into the solid region.

Files Needing Attention: GitUpKit/Interface/GIGraphView.m

Important Files Changed

Filename	Overview
GitUpKit/Interface/GIGraphView.m	Adds virtual-line path splitting and transition-node rendering, but endpoint-only quadratic classification leaves a small dashed overlap at a curved transition.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Virtual graph line] --> B[Find first real node]
  B --> C[Split path at node Y]
  C --> D[Dummy prefix]
  C --> E[Real branch portion]
  D --> F[Thin dashed stroke]
  E --> G[Solid branch-width stroke]

Loading

_{Reviews (1): Last reviewed commit: "Fix real branches drawn as virtual" | Re-trigger Greptile}

[greptile-apps]

Quadratic transition remains dashed

When a virtual branch changes columns at its first real node, these endpoint checks assign the entire quadratic corner to dashedPath even though its control point extends below transitionY, causing a visible dashed overlap in the solid branch segment.

Knowledge Base Used: Commit graph rendering

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[antons]

This is a theoretical concern that does not apply to the actual path geometry in GitUp. This code will not run for the quadratic corner at the first real node, because its start.y > transitionY, control.y == transitionY, and end.y < transitionY. GIGraphView.m:882–920 constructs points on the opposite sides of the node, GIGraphView.m:988–996 uses the node as the control point, GIGraphView.m:1014 sets transitionY from the same node.

[greptile-apps]

You're right — with the actual path construction, this case is handled by the mixed-endpoint branch: start.y > transitionY, control.y == transitionY, and end.y < transitionY. The quadratic is monotonic across the transition, so _QuadraticCurveParameterForY finds the valid split and the solid portion begins at the transition rather than leaving a dashed overlap. My concern depended on a control point extending past transitionY, which GitUp does not generate here. I'll withdraw this comment.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.