Why is git removing rows that were added on one branch when merging?

Question

I’m using git for keeping track of the development of a small web site of mine. I have two branches at the moment:

a master branch with code that is (supposedly) ready for deployment
a dev branch where I try out things until I think they are ready for deployment

In order to get used to good habits in case of upscaling the development to more people I usually merge the master branch with the dev branch before checking out the master branch and merging the dev into it – so as to be able to resolve any conflicts in the dev branch instead of on the master.

Last time i did so, some of the code just disappeared (css code for id="all_text", see code further down). I figured that this was because the code was absent in the master branch and because I was moving the master code into the dev branch (but it’s not how I remember it to behave), so I undid the merge (git reset --merge; I’m on git 1.7.0.3), checked out the master branch and merged it with the dev branch. Same result – most of the code in the #all_text css disappeared.

I’m at loss as to why this is happening. The most recent changes are on the dev branch so they should reasonably be carried over in a merge, instead they are deleted.

Is there any way to solve this without doing the ugly hack of copying the contents of the documents in dev manually to master?

Dev content (index.css)

body {
    margin:0;
    padding:0;
}

/* attributes for the <div> that encapsules the h1 and the encouragement */

#all_text {
    position: relative;
    height: 50%;
    width: 70%;
    margin-top:8em;
    margin-left:auto;
    margin-right:auto;
    text-align: center;

//  background-color: yellow; // Trace code to better see the design
}

h1 {
    position: relative;
    text-align: center;

    font-size: 700%;
    color: #4970A8;
/*  color: #5AA0FF; */
    text-shadow: 4px 4px 8px gray;

//  background-color: green; // Trace code to better see the design
}

div.encouragement {
    position: relative;
    width: 70%;
    bottom: 25px;

    color: #4970A8;
    font-size: 170%;

//  background-color: red; // Trace code to better see the design
}

Master content (index.css)

#all_text {
    position: relative;
}

h1 {
    color: #4970A8;
/*  color: #5AA0FF; */
    text-align: center;
/*  text-vertica-align: center; */
    font-size: 700%;
    position: relative;
    top:30%;

    text-shadow: 4px 4px 8px gray;
}

div.encouragement {
    color: #4970A8;
    text-align: center;
    font-size: 150%;
/*  position: absolute;
    top: 5%m;
    left:7%em; */
/*  text-shadow: 2px 2px 8px gray; */
}

Merged content (index.css)

#all_text {
    position: relative;
}

h1 {
<<<<<<< HEAD
    position: relative;
    text-align: center;

    font-size: 700%;
    color: #4970A8;
/*  color: #5AA0FF; */
    text-shadow: 4px 4px 8px gray;

//  background-color: green; // Trace code to better see the design
}

div.encouragement {
    position: relative;
    width: 70%;
    bottom: 25px;

    color: #4970A8;
    font-size: 170%;

//  background-color: red; // Trace code to better see the design
=======
    color: #4970A8;
/*  color: #5AA0FF; */
    text-align: center;
/*  text-vertica-align: center; */
    font-size: 700%;
    position: relative;
    top:30%;

    text-shadow: 4px 4px 8px gray;
}

div.encouragement {
    color: #4970A8;
    text-align: center;
    font-size: 150%;
/*  position: absolute;
    top: 5%m;
    left:7%em; */
/*  text-shadow: 2px 2px 8px gray; */
>>>>>>> master
}

What happened to most of the text in the #all_text{…} section?

Thanks on beforehand.

Update: Added the merge-base (according to dyng’s instructions).

Running git show $(git merge-base dev master) gives me this:

diff --git a/www/index.css b/www/index.css
index b837a87..d8c48ef 100644
--- a/www/index.css
+++ b/www/index.css
@@ -1,25 +1,44 @@
+body {
+       margin:0;
+       padding:0;
+}
+
+/* attributes for the <div> that encapsules the h1 and the encouragement */
 #all_text {
        position: relative;
+       height: 50%;
+       width: 70%;
+       margin-top:8em;
+       margin-left:auto;
+       margin-right:auto;
+       text-align: center;
+               
+//     background-color: yellow; // Trace code to better see the design
 }

+
 h1 {
        color: #4970A8;
 /*     color: #5AA0FF; */
        text-align: center;
-/*     text-vertica-align: center; */
+       display: inline-block;
        font-size: 700%;
        position: relative;
-       top:30%;
+       left:0.5em;
+

        text-shadow: 4px 4px 8px gray;
+               
+//     background-color: green; // Trace code to better see the design
 }

-div.encouragement {
+span.encouragement {
        color: #4970A8;
-       text-align: center;
-       font-size: 150%;
-/*     position: absolute;
-       top: 5%m;
-       left:7%em; */
-/*     text-shadow: 2px 2px 8px gray; */
+       font-size: 170%;
+       position: relative;
+       top: 3em;
+       right:18em; 
+
+
+//     background-color: red; // Trace code to better see the design
 }
\ No newline at end of file

`git merge-base dev master` will tell the merge base (it's a commit) when merging `dev` and `master`, what does `index.css` look like at that commit? ( here is a one-line command: `git show $(git merge-base dev master):/path/to/index.css` ) — dyng, Dec 03 '13 at 08:43
Thanks for the clear instructions on how to do it, see the update above for the result. (I ran it without the path specification as it gave a fatal error when I included the path, but I left out the other files in the update above.) I ran it when in the dev branch. As far as I understand the +’es tells me what rows have been added in the dev branch as compared to the master branch (and the -’es what has been removed) but I’m not quite sure what to do with that info – I already know what I want to keep and not, but git doesn’t ;) ). — Elias Mossholm, Dec 04 '13 at 14:16
@dyng Maybe my comment to VonC is of help too (the fact that I updated things server side and fetched it to master while doing separate development on the dev branch). But that doesn’t explain why git would discard of the body selector that I added in the dev branch (for example). — Elias Mossholm, Dec 05 '13 at 04:40
The merge-base info implies that in *master* branch, lines in "all_text" were added **then deleted**. While *dev* remains the same as merge-base, in *master* those lines were deleted. During a merge, if one branch differs from merge-base and the other remains the same, Git will always accept the changed one as a merge result. — dyng, Dec 05 '13 at 10:35

score 1 · Answer 1 · answered Dec 03 '13 at 08:53

1

I usually merge the master branch with the dev branch before checking out the master branch and merging the dev into it

In order to avoid those merge issues, it would be better to:

rebase dev on top of master
before merging dev to master

That way, you reapply (rebase) your changes on top of master, making any "disappearance" of your dev code unlikely.

answered Dec 03 '13 at 08:53

VonC

1,262,500
529
4,410
5,250

Would that work once this scales to more users? Or would I be overwriting anything other people have merged into master then? – Elias Mossholm Dec 04 '13 at 13:39
@EliasMossholm yes it will work. As long as you rebase first on top of an up-to-date master, before pushing, you won't overwrite anything. – VonC Dec 04 '13 at 13:42
I tried it and still lost some code I wanted to keep (eg. the "body" section at the top on the dev branch version). I also got a conflict that needed to be resolved, so I aborted the rebase operation, but thanks for the effort/tip. – Elias Mossholm Dec 04 '13 at 15:03
The problem might be that after the last push I did to the server, the page looked strange in the mobile browser so I undid the last commit (the last push) directly on the server and then fetched/pulled it to the local master (if I remember the steps correctly). – Elias Mossholm Dec 04 '13 at 15:07

score 1 · Accepted Answer · answered Dec 05 '13 at 11:10

1

I undid the last commit (the last push) directly on the server and then fetched/pulled it to the local master.

It's the key to your problem. Revert that commit in master by

git checkout master
git revert <sha1_of_that_commit>

then merge will work fine.

But as VonC said, merge/pull master to dev is not a so good idea, git rebase or git pull --rebase should be better.

answered Dec 05 '13 at 11:10

dyng

2,854
21
24

I agree. +1. But as I said in my answer, I prefer pulling (and rebasing) first before pushing. Pushing first can be... dangerous ;) http://imgur.com/nDNPyYd – VonC Dec 05 '13 at 11:29
Hmm… I checked out only the css file first, to see that it was the correct commit I was checking out, but then I got a bit caught up in it and merged with dev instead of reverting to the associated commit first. This gave a merge conflict which I resolved by simply pasting in the most actual version of index.css and committing. This gave a "Your branch is ahead of 'origin/master' by 8 commits." comment when running git status. I tried to get rid of it by reverting master to an earlier stage and then merging (as suggested by dyng above) but… – Elias Mossholm Dec 05 '13 at 13:07
… that gave me a fatal error "fatal: Commit db6ebec56b1e4f1650dbb8b5a9bedaf057c6e400 is a merge but no -m option was given." so I tried with an earlier commit point which was not a merge, which gave me "Finished one revert. error: There was a problem with the editor 'vi'. Please supply the message using either -m or -F option.". As far as I could see that was a succcess but maybe it failed b/c of the missing commit comment? In any case, when I then ran "git merge dev" I got the message "Already up-to-date."… – Elias Mossholm Dec 05 '13 at 13:11
… Since then, whenever I switch from dev to master I get "Your branch is ahead of 'origin/master' by 2 commits.", which I don’t understand – as far as I see I _am_ on the master branch, so how can I be ahead of it? It makes sense from the perspective that there are changes in dev that are not yet in master, but that should reasonably mean that "Your branch is ahead of origin/master…" should show up when I check out dev, but it doesn’t (only when I check out master). I’m sorry I messed this up a bit and I appreciate your kind help dyng and VonC. How do I get rid of "Your branch is ahead…"? – Elias Mossholm Dec 05 '13 at 13:21
@EliasMossholm You are misusing *revert*. `git revert` is such a confusing command which shares the same name with *svn* but has absolutely different meaning. The real counterpart of *revert* in *svn* is `git reset`. – dyng Dec 05 '13 at 14:04
First, find correct commit you want *master* reset to (using `git reflog` or `tig` or something you prefer), then `git reset --hard `. – dyng Dec 05 '13 at 14:07
@dyng I tried `git reset --hard 4ef077474829c7d8f5de2dcc8057ae676ed3f73e` (a commit that seemed like a good point to start over from). But when I ran `git status` I still got `Your branch is behind 'origin/master' by 13 commits`, with the addition of `, and can be fast-forwarded.` This was a bit confusing to me but [this answer](http://stackoverflow.com/questions/9512549/how-to-fast-forward-a-branch-to-head) solved it. Thanks again. – Elias Mossholm Dec 14 '13 at 08:36

Why is git removing rows that were added on one branch when merging?

2 Answers2