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-rebase to transplant the commits instead of merging them, but at the time the user who created these was still quite new to Git...
(larger version)
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).
(larger version)
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.
Posts
2 comments :
This is hilarious.
I'm not sure if this is hilarious or depressing, maybe a little bit of both :P. What can we do when a repository has such a insane number of commits though? Maybe what could be done is that instead of showing every branch that got merged, only show the requested branches. E.g., in the case of 'gitk master maint' only show the development of master and maint, and show merged-in branches as one point in the graph, instead of as a full line with all the commits made on that branch. This reduces the amount of information you have (you lose the information on what exactly was merged in), but with such a huge amount of data, gitk is hardly useful anymore anyway. I know that I would love an option to trim merged-in branches when looking at git.git!
Post a Comment