The first image is from a set of octopus merges that occurred in the history. This probably would look better if we had just used
git-rebaseto transplant the commits instead of merging them, but at the time the user who created these was still quite new to Git...
What's even worse about that particular rendering is the branches on either side. This was taken with the following gitk preferences set:
Maximum graph width (lines): 80
Maximum graph width (% width of pane): 90
Even with those settings, gitk still does not have enough space to show all of the active branches passing through this particular point in time (see the lines cut off on the upper right corner). In case you are wondering, yes, nearly all of those merged together later on. A few haven't yet.
This second image was taken from a more recent point in the project's timeline, during the same gitk session, and with the same preferences. We've obviously reduced the number of active branches somewhat, and there is now space for the commit subject lines (which I had to redact) and tracking branch labels (also had to be redacted).
There is still an octopus here ("Cauterize prior batch m"), but this one was automatically generated by a script we developed and was not directly caused by a user. The script takes a single commit and merges it to all branches that share a common prefix. I don't have the repository on hand right now, but I think this particular octopus was created while we were merging one commit to ~80 branches. In this case 4 branches were already fully merged with a 5th, and we wanted to keep it that way after the new commit was merged to all 80 branches. To do that the script remerged these 4 by way of an octopus.
Before you can ask, no, this is not an imported repository. This was all created in git, using the core porcelain and git-gui.