Going further afield into tangent, I love the looks of these "subway diagrams" of the commits, but I keep thinking that as great as they look and as nice screenshots as they make what I'd love to see a Git UI do is something very different: take a --first-parent approach by default and use a drilldown/expandable view of commits past first parent. It would look a lot more boring in screenshots, but could be a great way in practice to ease people into the two dimensional git DAG without making it seem so messy/busy by default. Many projects it would provide a good "PR focused" view of the repository up front and center (without being reliant on specific PR tools/APIs, only that those PR tools create merge commits).
Going off to a different tangent: the vertical colored lines down the side of a list of chronologically ordered items to show reply threads was a visualization I first spotted in the early oughts or late 90s from a showcase of Microsoft Research Visualizations and so Microsoft Research has published research and had patents on it at one time. Those patents have all since expired, I believe, but it's interesting to note that it was on some minds even back then, which was neat, and curious to wonder what if a Microsoft product had embraced it earlier. (I recall the demo felt a lot like Outlook's email list and the impression was that was what they were trying to sell it as a possible tool to the Outlook team. Which seemed a neat idea for email visualization, though I think Outlook decided that strict temporal ordering wasn't necessary for reply threading that users were happy enough with.)
Hi. In Fork you can expand/collapse nodes in the graph. Collapsing all (i.e. --first-parent) and then expanding particular merge commits is also possible.
Good to know. I'm just thinking it might be useful as a default.
I'm also thinking that it's related to that "why didn't Outlook end up using 'subway diagrams'?" question: maybe strict chronological ordering isn't necessarily the best focus for commit ordering with respect to "top-level" merge commits.
Anyway, not a direct criticism of your app specifically, more just a long slow stewing of my own thoughts on the subject that I likely won't ever get around to even prototyping, in case they do congeal into something worth prototyping. You are certainly ahead of me there by having built a thing, and I appreciate that.
Right now I don't think enough people appreciate the idea of --first-parent as a default in as many views as possible (especially as opposed to how many seem to prefer squash/rebase-based workflows solely based on gut reactions to how the "subway diagrams" can look), and I like mentioning that in case it sparks ideas for other people to maybe find workflows that they like more than that (and can take advantage of the 2D nature of the git DAG possibly better than "straight line" approaches).
I'm probably rambling at this point, because yeah I still haven't quite found the right "shape" of this idea and it is interesting to think out loud about it.
Going off to a different tangent: the vertical colored lines down the side of a list of chronologically ordered items to show reply threads was a visualization I first spotted in the early oughts or late 90s from a showcase of Microsoft Research Visualizations and so Microsoft Research has published research and had patents on it at one time. Those patents have all since expired, I believe, but it's interesting to note that it was on some minds even back then, which was neat, and curious to wonder what if a Microsoft product had embraced it earlier. (I recall the demo felt a lot like Outlook's email list and the impression was that was what they were trying to sell it as a possible tool to the Outlook team. Which seemed a neat idea for email visualization, though I think Outlook decided that strict temporal ordering wasn't necessary for reply threading that users were happy enough with.)