[git][flyweight] something messed up with master and develop branch
Dear Git connoiseurs: I've realized that my master and develop branches at boostorg/flwight appear collapsed: https://github.com/boostorg/flyweight/network Yet I am seemingly able to treat them separately: commit to develop, test, merge to master etc. The only weird thing is the diagram above and the fact that the commit log in master doesn't have the usual "Merge branch 'develop'" commits: https://github.com/boostorg/flyweight/commits/master Any clue what's going on? Thank you! Joaquín M López Muñoz Telefónica
On 11/11/2014 02:49 PM, Joaquin M Lopez Munoz wrote:
Dear Git connoiseurs:
I've realized that my master and develop branches at boostorg/flwight appear collapsed:
https://github.com/boostorg/flyweight/network
Yet I am seemingly able to treat them separately: commit to develop, test, merge to master etc. The only weird thing is the diagram above and the fact that the commit log in master doesn't have the usual "Merge branch 'develop'" commits:
https://github.com/boostorg/flyweight/commits/master
Any clue what's going on? Thank you!
Joaquín, the diagram and the history appears to suggest that you've merged from develop to master some time ago, and then continued to push changes to master, as opposed to develop. Maybe, you just forgot to switch back to develop? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
Vladimir Prus
Joaquín,
the diagram and the history appears to suggest that you've merged from develop to master some time ago, and then continued to push changes to master, as opposed to develop. Maybe, you just forgot to switch back to develop?
I don't think so: I'm doing commits to develop (and I always check this is the active branch), then merging to master. Take for instance https://github.com/boostorg/flyweight/ commit/88a5aaeb820686ea8abde169d274441f1f5d3b39 I'm positively sure (I made it 30 min ago) that the seqyence was * Switch to develop * Commit * Push (at this time I verified visually the change didn't appear in master) * Switch to master * Merge * Push Yet the commit in *develop* appears as if it came from *master*! I can do some irrelevant commits on demand if that helps you figure out what's going on Joaquín M López Muñoz Telefónica
On 11/11/2014 03:05 PM, Joaquin M Lopez Munoz wrote:
Vladimir Prus
writes: Joaquín,
the diagram and the history appears to suggest that you've merged from develop to master some time ago, and then continued to push changes to master, as opposed to develop. Maybe, you just forgot to switch back to develop?
I don't think so: I'm doing commits to develop (and I always check this is the active branch), then merging to master. Take for instance
https://github.com/boostorg/flyweight/ commit/88a5aaeb820686ea8abde169d274441f1f5d3b39
I'm positively sure (I made it 30 min ago) that the seqyence was
* Switch to develop * Commit * Push (at this time I verified visually the change didn't appear in master) * Switch to master * Merge
Did you use --no-ff option, so the a merge commit is created as opposed to 'master' just changed to point to a different commit id? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
Vladimir Prus
Did you use --no-ff option, so the a merge commit is created as opposed to 'master' just changed to point to a different commit id?
I use the default setting of TortoiseGit, which has "No Fast Forward" unchecked. I don't remeber ever changing this (but might be wrong), and this weird behavior has only come up recently. Joaquín M López Muñoz Telefónica
On 11/11/2014 03:16 PM, Joaquin M Lopez Munoz wrote:
Vladimir Prus
writes: Did you use --no-ff option, so the a merge commit is created as opposed to 'master' just changed to point to a different commit id?
I use the default setting of TortoiseGit, which has "No Fast Forward" unchecked.
If it is unchecked, I presume it means that fast forward *is* enabled, which is what you see. Try checking that option.
I don't remeber ever changing this (but might be wrong), and this weird behavior has only come up recently.
I can only imagine that at one point, you've pushed same commit to develop and master, and from that point onward, git merge happily does fast forward. Try making dummy commit on develop, push it, make it sure it's only on develop and do no-ff merge to master. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
Vladimir Prus
I can only imagine that at one point, you've pushed same commit to develop and master, and from that point onward, git merge happily does fast forward. Try making dummy commit on develop, push it, make it sure it's only on develop and do no-ff merge to master.
Yes, that did the trick: https://github.com/boostorg/flyweight/ commit/12f2db37b5b95ca6d547f8bf1c4f1dbd5eedb804 Now the network diagram shows two different lines for develop and branch as (I guess) it should be. Shall I keep doing no-ff merges or is it OK to continue with the default (no no-ff) from this point on? Joaquín M López Muñoz Telefónica
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. Here's some example were you can see 3 branches, two of which are same (`develop` and `simplification`) while `master` branch does not have last commit: https://github.com/boostorg/lexical_cast/network After `git merge develop` will be done at the `master` branch, all the three lables will be pointing to a single commit. The only strange thing with boostorg/flyweight is that commit https://github.com/boostorg/flyweight/commit/26b6b4887f05300a17beee32c1bd596... merged two lines, while usually we need to `merge develop to master` and `merge master to develop` to achieve that for first time. -- Best regards, Antony Polukhin
Antony Polukhin
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. Joaquín M López Muñoz Telefónica
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.
participants (4)
-
Andrey Semashev
-
Antony Polukhin
-
Joaquin M Lopez Munoz
-
Vladimir Prus