When doing git log --decorate --oneline --graph
in one of our repositories shortly before Christmas, we found that the following structure had appeared (rotated to emphasize the tenuous festive theme):
How did this pattern in the commit graph arise?
This is deliberately somewhat silly, of course, but there's a interesting point here — it's often difficult to see how to interpret particular patterns in the commit graph when you see them in you git history browser.
In this case the situation was that there was an unpushed commit at the tip of the master
branch in one clone of the repository. Then git pull
was run many times in the same repository, over a period of time when there was lots of new work being done upstream. (In this case, it happened because of an automated script, but the same thing can happen if a developer just pulls repeatedly into a branch in order to keep it up-to-date, rather than, say, rebasing.)
Every pull when there were new commits upstream created a new merge commit, since there was always a commit in master
that wasn't in master
upstream.
Eventually, the history from the master branch in this repository was pushed upstream, so other developers saw this structure in the commit graph suddenly appear when they next pulled from the upstream repository.
If you have some history with a similar structure, and want to find out which commit / developer it was that caused this problem, you can just look down the line with the stars (basically following the first parent of every merge) until you get to the first non-merge commit. In the case in the picture, that was b275805
— the commit that should have been pushed earlier.
This is one reason people often prefer to use git pull --rebase
— it keeps your unpushed history simple.
To give credit where it's due, my colleague Matthew Somerville spotted this and worked out what was going on.