Use time-based commit ordering between parallel branches

[rowanj]

The ordering of commits in the history graph leaves much to be desired.

Topological sorting (parents always lower than children) is required to get the graphing to work at, or the grapher will scan to the beginning of time assuming that the parent hasn't been seen yet; but time-sorted commits actually show the comparative activity between branches, and makes the history view substantially more intuitive.

For the time being, I've reverted to topological ordering; but have time-sorted the refs before enumeration.

[beporter]

Assuming I'm understanding what you're talking about, that was another change in 0.15 that sat a little wrong with me. I get that the commits are ordered chronologically regardless of branch, but I find myself preferring the old way where all of the commits from a branch were a set of "grouped" rows. I have a feeling I'm repeating what @rowanj just posted above, just using dumber words.

In particular, the ref label from a just-merged PR was always immediately below the merge commit, which allowed me to use muscle memory to locate the leftover origin branch ref label and delete it quickly. In 0.15.1869, the position of that ref label could be placed "randomly" (meaning "not immediately below") in the list below the merge point.

[rowanj]

Yeah, that's pretty much it.

Having been working with it for a while, I much prefer the chronological ordering, but I can see where both would be good. Maybe it just needs to be toggle-able; or perhaps that's what you should get if you sort by the relative date field.

[beporter]

Yes! Drafting my last post, I was struggling to articulate a point about not being able to use the column headers to control row sorting without sacrificing the graph, but failed miserably and gave up on that idea. Using the date field might be an excellent mechanism for that exactly.

If it's possible to get chrono ordering AND keep the graph when clicking the Date column header, I would consider that ideal behavior. I always specifically avoided doing that before because the graph would get glitchy/disappear.

My only concern is that if the result is not purely chronological (rather still grouped by branches in the graph) then that may be frustrating for someone looking to scroll strictly by date.

[rowanj]

Yep, the glitch is because the graphing assumes (reasonably) that the parent of a commit is below the commit itself; which can be false in a couple of cases (i.e. git rebase -i with re-ordered commits).

This is deeply ingrained with the means by which the graph is created, but also with the overall design of the graph. If the parent of a commit has already been seen, we'd need to either be able to indicate that somehow, like draw a line back up to it and re-indent everything in between; or dynamically re-order the commits to bring the parent 'down' to the logical position.

[beporter]

Finally ran across a clear enough example to be able to post a screenshot.

The change in positioning is really throwing me off. Deleting the "2nd down" ref doesn't typically hurt anything, because (as we've discussed) it's really still on the remote and can be re-retrieved, but man is it annoying to clean up the old just-merged branch now in the confusion below the "main" (dev in this case) branch!