Re: [boost] [git][flyweight] something messed up with master and develop branch

Subject: Re: [boost] [git][flyweight] something messed up with master and develop branch
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-11-11 08:41:01

On Tue, Nov 11, 2014 at 4:26 PM, Joaquin M Lopez Munoz <joaquin_at_[hidden]> wrote:
> Antony Polukhin <antoshkka <at> gmail.com> writes:
>
>>
>> 2014-11-11 15:49 GMT+04:00 Joaquin M Lopez Munoz <joaquin <at> tid.es>:
>>
>> > Dear Git connoiseurs:
>> >
>> > I've realized that my master and develop branches at boostorg/flwight
>> > appear collapsed:
>> >
>> > https://github.com/boostorg/flyweight/network
>> >
>>
>> 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.