1

I don't understand the following GitLab graph and I'm lacking vocabulary to express my question precisely. For reference, the graph below shows:

I am not contributing to linux-kernel. Curiosity just drove me there and this GitLab graph confused me.

GitLab graph

(Ignore green branches)

Please, correct any wrong vocabulary in the following questions.

  • Between arrow 1 and arrow 2, the left side master branch has no commit, while the right one has some.

  • The arrow 1 shows a point where master is like "diverging" from master itself. But there is no commit between the moment it "diverges" and the moment it is merged. Then it is not really a branch? How is this called? Why one would do this, and how?

  • At arrow 2, the "diverged" master is merged back into master. What is the point of doing so? How is it called? A use case would help to understand.

  • Why is there a "hole" between the commit pointed by arrow 1 and the next commit on the right side master? How does this work?

I feel like all these points are connected by a git logic, but I can't figure out which one and my lack of vocabulary didn't help to find relevant search results.

NdFeB
  • 109
  • 12

1 Answers1

0

It happens every time you want to merge a branch (say, a feature) into another branch that hasn!t moved (with git merge --no-ff). If you allow gir to merge at will in that scenario, if does a fast-forward so there is no merge.... but if you want to make sure that the feature branch stays on the side and a new merge revision is created regardless, you use --no-ff and you are done. This is useful in caees when you want to be able to move features around. A simple example: backports. If you didn!t merge like this in this scenario, you would have a hard time knowing where the feature starts and where it ends.

eftshift0
  • 26,375
  • 3
  • 36
  • 60