Unrelated to fork itself, but I always wonder how do people implement the vertical colored lines representing branches and merges. This is present in almost all git desktop clients, and of course very useful.
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.)
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.
https://www.flickr.com/photos/jonasfonseca/3315600409/in/alb... (the official site link screenshots to flikr :)
it is part of my workflow for years. I prefer direct git commands. But sometimes it is nice to explore history and complex changes there. And most of the parameters are the same as `git diff ...` just `tig ...` with (almost always) same values for the ellipsis.
git log --graph --oneline --all