Why don't git branch diagrams track branches correctly?

Question

The screenshot below is taken from SourceTree. I created a simple git repository with several commits in it. For each commit, a comment indicates which branch I was on when I committed.

As you can see, the tree diagram is (possibly) not optimal in that the fixations for the masters do not have the same color and are not in the same strip. Why is this?

(The tree diagrams drawn by GitHub and BitBucket seem to suffer from similar issues, so this is not just SourceTree.)

Obviously, this does not really matter in this simple example, but in some of my projects we use the git -flow option, and it is often difficult to track each of the swimlanes git -flow "when you look at the tree diagram. This is partly due to that the tree diagram does not preserve every fin of the same color over time.

My suspicion is that the tree diagram is (possibly) suboptimal, since the git repo does not 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 (for example, when you join a branch), git does not know if the parent commit is “in the same branch” as child 1 or child 2. Or, in other words, it does not know which child was a branch, and which was a continuation of the trunk. Do I have this right?

Answer 1

As mentioned in other answers, this is simply the nature of Git: A git commit does not contain any information about which branch was enabled when the commit was committed. (And this information cannot be reliably deduced from the information that git supports, which, of course, includes the DAG.) It was a design choice made by the git authors. Mercurial, in contrast, stores the branch name with each commit. Git proponents claim this is bad because it prevents the creation of possible temporary branches to try to figure it out, and in addition, branch name clashes can easily occur. See, for example, Differences between Mercurial and Git .

Mercurial lawyers argue that storing a branch name with each commit is a good thing, as it simplifies the maintenance of an interpreted story. The fact that Mercurial stores the branch name with each commit is the main reason why the author Why I like Mercurial More than Git prefers Mercurial over Git.

Answer 2

In git, branches are implemented as a pointer to a set of changes.

This means that a particular set of changes can "belong" to several branches at the same time.

This means that it is allowed at runtime and after deleting a branch (or changing your schedule in any other way) - you cannot determine in which branch it was originally executed.

In your case, 94f458e applies to both master and release , so the graph is completely correct.

Answer 3

Entries are not "on" branches. Branches are nothing more than local names for commits that interest you. The important thing is that the story is a story in your repo. Focus on that. Commits 94f and 18d are part of the history of both branches; they are the ancestors of both release and master .

If your utility painted master on the left, its commit would be painted in blue, and all release unique pedigrees would be magenta.

This is more or less what @zerkms (and I supported him) said, only from a different perspective.