Conversation
9fef636 to
bbad667
Compare
rimrul
left a comment
There was a problem hiding this comment.
I don't love the positioning of the arrow labels overlapping multiple arrows, but there seems to be very little we can do about that.
bbad667 to
bc6fc86
Compare
It is a good idea to stay up to date, anyway, but in this instance the motivation is to get across the breaking changes in https://github.com/gohugoio/hugo/releases/tag/v0.148.0 that affect how layouts work (something that I am about to use when I introduce support for Graphviz diagrams). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
GitGitGadget deploys an Azure Function to act on webhook events. The documentation still points to the old location, but as of gitgitgadget/gitgitgadget@dbe71cb7 (Remove the code of the Azure Function, 2023-08-17), that location is no longer valid, because the respective source code moved to https://github.com/gitgitgadget/gitgitgadget-github-app. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As of gitgitgadget/gitgitgadget#609, GitGitGadget no longer runs on a single Azure Pipelines runner, but instead on GitHub-hosted GitHub Actions runners. Let's adjust the part that described the Azure Pipelines' names and purposes, talking about the GitHub workflows and Actions instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We no longer use Azure Pipelines (having traded their flexibility for the increased transparency of GitHub workflows). In other words, the exact steps can be inspected by everyone now, in https://github.com/gitgitgadget-workflows/gitgitgadget-workflows. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We now use GitHub workflows for synchronizing. While in the area, also mentioned the current Git GUI maintainer (this was somehow missed in a5db6b8 (Update git-gui references, 2025-08-21)). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
a36b6ca to
a2aad48
Compare
|
I force-pushed some changes. Range-diff
|
|
Updates can be adored here: https://dscho.github.io/gitgitgadget.github.io/architecture |
|
I did some fiddling with overlapping edges, unlabled edges, label placement and readability. What do you think of |
I love it! And I integrated your changes as b81468e. See it in action here: https://dscho.github.io/gitgitgadget.github.io/architecture |
I tried to add some Mermaid diagrams, but they simply do not look good. Graphviz offers much better control over the layout. Unfortunately, unlike Mermaid (which is a JavaScript library), Graphviz is a command-line program, and therefore not available in the browser. Fortunately, some helpful people maintain a WebAssembly version of Graphviz, which _is_ a JavaScript library: https://github.com/mdaines/viz-js Unfortunately, unlike Mermaid (which weighs ~25kB), the GraphViz WebAssembly weighs 1.4MB. But that's not quite correct, as Mermaid then loads another half megabyte, whereas `viz-js` does not load anything. The `viz-global.js` file was downloaded via: npm pack @viz-js/viz@3.17.0 tar Oxvf viz-js-viz-3.17.0.tgz package/dist/viz-global.js \ >static/js/viz-global.js Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There are some issues when adding SVGs inside <svg> HTML elements, e.g. that positioning can be harder than with <img> ones, as pointed out at git/git-scm.com#2052 (comment). Let's use <img> elements instead, passing the SVG via data URLs. There are more benefits to that: For example, most modern browsers allow copying an image into the clipboard that is specified as an `<img>` element, but not `<svg>` ones. Likewise, the "Open Image in New Tab" functionality typically only works with the former but not with the latter. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
No need to set a background color, is there? Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This can be done like so:
```graphviz {.engine="neato"}
digraph diagram {
A -> B
}
```
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Since the WebAssembly version of Graphviz is not exactly light (1.4MB at the time of writing), and since it is a waste to let everybody re-render the SVG client-side over and over again even though the diagram's definition hasn't changed, let's add a script that performs that rendering "on the server side" (more precisely: during deployment). This script takes no arguments and post-processes the output of Hugo in `public/`. For performance reasons, it requires the list of files that contain Graphviz diagrams. With this here site, it might not matter much because there are only a handful images here. However, I want to reuse the same method on git-scm.com where there _are_ thousands of files that do not contain any Graphviz diagrams, and therefore it is a necessary optimization to process only the files that _do_ contain Graphviz diagrams. To get that list, a new layout and page are added that Hugo processes, identifyng said list of files and writing the result to `public/diagram-list.html`. Since this script runs via Node.JS and therefore lacks the convenient built-in HTML parser of browser-based JavaScript engines, a prerequisite is now to run `npm install` so that the `node-html-parser` package is available. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Since we're generating `<img>` elements anyway, might just as well keep that accessibility support. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This avoids the 1.4MB download on the client-side, in favor of inlined, small SVG elements. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
b81468e to
24de833
Compare
Range-diff
|
|
@rimrul as before, I pushed to my fork so that it can be seen in action: https://dscho.github.io/gitgitgadget.github.io/architecture |
A picture says more than a thousand words, they say. Note: I originally intended to add two Mermaid diagrams. It turned out, though, that there is too little control over the layout using that method, and I turned to a much more complex yet equally more satisfying solution: Graphviz. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
I did some fiddling with overlapping edges, unlabled edges, label placement and readability. Signed-off-by: Matthias Aßhauer <mha1993@live.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
24de833 to
9325a7c
Compare
|
LGTM |
After gitgitgadget/gitgitgadget#609 has been addressed, the architecture is noticeably different. Here is an attempt to visualize the new lay of the land: