Why do git branching diagrams not track branches "correctly"?

Question

The screenshot below is taken from SourceTree. I created a simple git repo with a few commits in it. For each commit, the comment says what branch I was on when I made the commit.

As you can see, the tree diagram is (arguably) suboptimal in that the commits to master are not all the same color, nor are they in a single lane. Why is this?

(The tree diagrams drawn by GitHub and BitBucket seem to suffer from similar problems, so it's not just SourceTree.)

Obviously it doesn't much matter in this simple example, but in some of my projects we use a variant of git-flow, and it's often difficult to keep track of each of the git-flow "swimlanes" when you look at the tree diagram. In part, this is because the tree diagram doesn't keep each swimlane the same color over time.

My suspicion is that the tree diagram is (arguably) suboptimal because the git repo doesn't actually contain enough information to draw the tree diagram the way I want it. In particular, when two commits are children of a common commit (e.g. when you branch), git doesn't know whether the parent commit is "on the same branch" as child 1 or child 2. Or, put another way, it doesn't know which child was the branch, and which was a continuation of the trunk. Do I have this right?

Answer 1

In git "branches" are implemented as pointer to a changeset.

It means, that a particular changeset may "belong" to several branches simultaneously.

That said - it is resolved in runtime and after you delete a branch (or modify your graph in any other way) - you cannot tell what branch it was committed to originally.

In your case the 94f458e changeset does belong to both master and release so graph is perfectly correct.