On Tue, Nov 11, 2014 at 4:26 PM, Joaquin M Lopez Munoz
Antony Polukhin
writes: 2014-11-11 15:49 GMT+04:00 Joaquin M Lopez Munoz
: Dear Git connoiseurs:
I've realized that my master and develop branches at boostorg/flwight appear collapsed:
Actually this is good. In GIT branches are determinated by their labels: see 'master' and 'develop' labels at the boostorg/flyweight commits line https://github.com/boostorg/flyweight/network
Two unmatching lines of commits mean that content of those lines differ, which is not what we usually want from `master` and `develop` after merge.
OK, then why the two line layout during Feb-Jul on this?
https://github.com/boostorg/multi_index/network
Here, master was perfectly aligned with develop after every merge, yet the network diagram displays a different line for each branch.
The content in two git revisions can be identical but these would be distinct commits nevertheless. I think, this is because these commits have different parents, dates or some other attributes, but I'm not a git expert to tell for sure. Anyway, different branches referring to these commits will appear separate in the graph. If you merge one of the branches into the other, you'll create a new commit that has two parents that are heads of the two branches. This new commit is what you see as a merge commit, and it becomes the current branch's head. If you switch to the other branch and merge the first one, this will be a fast forward merge (i.e. no commit will be done), and both branches will refer to this one commit. From this point on, as long as you make changes to one branch and merge in the other, the merges will be fast forward (i.e. will simply change the commit the branch refers to). The --no-ff argument forces a merge commit even if fast forward is possible.