For anyone wishing to learn why git is the way it is, I always recommend reading Git From the Bottom Up [0]. I don't consider myself a git guru, but I found this to be a really great read to understand the underlying concepts.
Since the git commandline isn't ever going to be anything but insane and confusing, it really helps to be able to visualize what's going on. I think a sizeable portion of developers reason about their work graphically, even though their work appears textual. Being able to do this successfully demands an iron-clad understanding the tools, and/or tools which map neatly and consistently to concepts.
The concepts behind git operations aren't hard. It's the incoherent commands that make people miserable, confused and mistake-prone. Git operations become crystal clear when represented graphically.
This the the best tool I’ve found to demonstrate to people, how commits that no longer appear in your history due to rebase or amend etc, are still there in your repository.
Zen mode works ~1 out of 3 tries. The other 2, it doesn't render anything other than the top part.
Seems a hard refresh (command+shift+r) does the trick on chrome
Sounds vaguely familiar, and indeed I had bokmarked a site which did this exactly (just more elaborate, IIRC was built as a complete tutorial). Site (https://news.ycombinator.com/item?id=7450528) is dead now unfortunately, would have been good to get inspiration from. https://learngitbranching.js.org is still alive though.
It's the same guy so that probably explains why it looks familiar. According to the commits in this repo the website you refer to was the same content, only slightly delayed compared to the github page.
https://github.com/onlywei/explain-git-with-d3/commit/93fe62...
Somewhat of an aside, has anyone seen a way to visualize this type of graph without javascript? I'm looking to visualize hundreds of graph relationships and am hoping to not use JS. Admittedly though this example looks fairly performant, all the other ones i've seen are super laggy.
Ultimately i think i just want to find a decent way to use CSS to replicate this style - but i've not seen any CSS gurus manage to produce that.
The graphviz tools, also known by dot (the most well-known tool), are a good way of visualizing smallish graphs, up to a few thousand nodes. Although do note that graph layout tends to be heavily dependent on what kind of graph you actually want to visualize; an algorithm that works well for one type of graph may look atrocious for other kinds of graphs.
The algorithm used by dot (Sugiyama layout) works well for trees or any other graph where the structure is well-approximated by a tree. Control-flow graphs are the prototypical example of the latter (being the use case dot was explicitly designed for), but the VCS commit graph is also going to fit in well in this model. If you have a graph which has many more cycles in it, or has a crisscrossing connectivity pattern like a hypercube, the resulting layout from dot is going to be a giant ball of twine.
Interesting. In case you're curious: The graph is git-like structure, but a tree. Trees of close-to-b-trees specifically, where each (key) value can point to another tree. There's really no limit to how wide these are, or how many connected trees there are - so i'll have to put artificial visualization limits on this. Still, i'd like to be able to view large trees of trees, with thousands of nodes in a performant manner.
Most demos i've seen on JS libraries have been laggy with just a handful of nodes - but they're also trying to do fancy animations/etc by default. Hopefully i can hook up D3 with some minimal effort - or perhaps render it in a game library. /shrug
d3 is primarily a javascript tool to turn data into structure - kind of like React. You may want to render to SVG (like the link this submission is about) or canvas, and then just update a few attributes/transforms on user-input, like panning, scrolling, etc. That way, the browser does the hard work of rendering the nodes, and the updates are pretty light on the javascript-side.
This is why I refuse to use Git from the command line -- it all makes perfect sense visually. Why mess around with hashes when you could just be clicking on the commit you want in a GUI and telling it to move?
From my little testing it seems like uBlock doesn't make a difference (shows 0 blocked elements) and it's really the reloading that does the trick. It seems to switch between working and not working every few seconds.
Edit: I just tested a bit more and last time the non-working period was a good minute. I'll stop DoSing now.
Probably one of your extensions blocking it. Turn off stuff like ublock and privacy badger and reload. I tried on Mac Firefox and it does indeed fail in even safe mode.
For anyone wishing to learn why git is the way it is, I always recommend reading Git From the Bottom Up [0]. I don't consider myself a git guru, but I found this to be a really great read to understand the underlying concepts.
0: https://jwiegley.github.io/git-from-the-bottom-up/