Feature Request: History display enhancements.

[cornelius-dol]

This is a small QOL request which I have never seen in any other git tool. Simply put, I want to be able to designate a list of branches that should be considered "trunks" (IOW, main branches, which affect deployed systems), and as such should always be displayed leftmost in the history in the order specified, and in the same color for the entire history (with the branch line drawn dashed or faded all the way to the top, similar to how the head to working directory is currently drawn). There would only be a relatively small number of such branches, less than a dozen, and 3 or 4 for most projects.

Consider this project which has four trunks in its release cycle, stable, release, qa, and develop (and at any given time a hundred or more branches off these):

Here a change was made on stable (a hotfix), and then merged stable -> release -> qa -> develop. But the visual path of the merge zig-zags, making what happened just a little unintuitive. If the history graph locked these trunks' order left to right as specified, then it would uniformly merge from right to left, going from stable to develop. Moreover, the main branches would always be in the same place, so it would be visually intuitive when something happens to them, and which of them it happens to.

I imagine this could be a simple project setting just as a comma separated list which would only impact the history rendering to always drawn the nominated branches first and in the order given. After that it would do what it is currently doing.

Another enhancement that would be super-helpful if hovering a history line would display the branch/tag name as it is at that point so one doesn't have to trace them down the list. For visual reference here's a somewhat more busy set of merge activity that would be helped by this:

My final request would be for the graph to always render a branch even if branched at a "head" commit as diverging, so that branches are always represented as "branching". So the following, for example, would be not drawn in a straight line but pictured as dev/ld/... branching from "develop" (note, this would not apply to tags):

Please ask if you want further rationale to justify this. I imagine the changes are not difficult, but I could be way off base on that.

[jorio]

Thank you for the detailed request! I understand the rationale, and I also find it disorienting when branch colors are reassigned as the shape of the graph changes.

I have a rough idea of how this could be implemented. The graph could reserve a fixed column (and a color) for each "sticky branch". As the graph builder works its way from the top down, it won't insert any commits into a reserved column until it sees the first commit in the matching sticky branch.

A limitation comes to mind: when a commit is shared by several sticky branches, it will only appear in a single column, but I suppose that's an acceptable tradeoff.

(By the way, I'm open to other names than "sticky branches" if you have other ideas. We just need a reasonably short name so it'll fit into menus/dialogs neatly.)

My final request would be for the graph to always render a branch even if at a "head" commit as diverging, so that branches are always represented as "branching". So the following, for example, would be not drawn in a straight line but pictured as dev/ld/... branching from "develop" (note, this would not apply to tags):

In this case, I think my idea would work. If you set develop as sticky, the graph will set aside the leftmost column for it. As the graph builder processes commits from the top down, it will not insert any commits into the leftmost column until it reaches commit 03260f0. So, dev/ld... will be shifted to the right until 03260f0, at which point its line will join the first column.

it would be super-helpful if hovering a history line would display the branch/tag name so one doesn't have to trace them down the list

This makes sense, but this might be a bit more involved, because the graph may have to be reworked to cache the refs that are reachable from each line. This may have performance implications so I'll proritize the sticky branches first.

[cornelius-dol]

Looking forward to see what you come up with.