1

Please help me understand why the git log shows an additional purple line for a merge into the develop branch.

We use gitflow so the blue line represents commits directly to develop. The yellow line is the master branch were we merge in releases. The other lines are releases or hotfixes.

In this scenario the bright green line was a hotfix created off of the master branch. There was one commit on the hotfix branch and then it was "finished" (i.e. merged into develop and master). The commit for the merge in master makes sense to me since I see the bright green line merge into the yellow (master) line. What doesn't make sense to me is the introduction of the pink line which shows the merge of the hotfix branch into the develop branch. I would expect the bright green line terminate into the blue line. The graph makes it look like develop was branched at the "Throw exception" commit when it wasn't.

git log looks similar (there is a dark blue line in there that's hard to see).

enter image description here

I have a theory but I wanted this to be confirmed. When I committed the change "Added Raygun integration" locally, there was an outstanding change that I hadn't fetched and merged in from origin (the hot fix integration). I think the pink line shows a diverge because the "Added Raygun integation" commit was before I merged the hot fix commit. The develop branch was then reintegrated when I merged origin into my local and pushed. If this is the case, if I had pulled the outstanding commit from origin first, then committed my change, would the "Merge branch 'hotfix/2.5.1' commit show merging to the blue line?

Brett Mathe
  • 6,429
  • 7
  • 23
  • 24
  • It's probably too late, but Aaron's is okay with you posting their commit history online and in public? – Makoto Jan 28 '16 at 00:06
  • `The graph makes it look like develop was branched at the "Throw exception" commit when it wasn't.` Yes it was! You have two commits done with the same ancestor, the develop branch diverges. This is classical, if you don't want this temporary branching, you can force fast-forward. – Ôrel Jan 28 '16 at 00:34

1 Answers1

1

Your theory is correct. There's not much else to add except to say that in git, the word "branch" is ambiguous: there are branch names like develop, master, and hotfix/2.5.1, and then there are the branching and merging lines you get by drawing the commit graph. A branch name simply identifies a particular commit as being "the tip commit for that branch", but that commit may be on any number of other branches as well. A merge simply adds a new commit that draws lines back to at least two existing commits.

These automated graph-drawers like to allocate a new color to secondary merge lines. That is, they pick one side of the merge (the "first parent" side) as the "main" line and keep that color going to previous commits, but use a different color for the other side. Since there's an extra merge in there, you get an extra color.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Here is a [related question](http://stackoverflow.com/questions/25068543/what-exactly-do-we-mean-by-branch) (about the ambiguous nature of the term "branch"), which was, incidentally, also answered by torek :) – jub0bs Jan 28 '16 at 08:37