Automerge issues

Question

Somehow I messed up our master branch as well as the feature branch I used to mess up the master branch with. Now I'm attempting to fix it but having trouble. For what it's worth, I have identified the commit that I need to "roll back" to in both the master and feature branches, so I believe the original problem has been removed.

PROBLEM: When I merge the feature branch in to master, it seems that auto-merge is removing some code in the feature branch and not merging it in to master. It doesn't give me the opportunity to resolve it as a merge conflict...it just simply doesn't move those pieces of code over in to master.

A HACK: I found that if I went in to one of the affected scripts (account/views.py) in the feature branch and removed a space or something it would then force me to resolve it as a conflict and I could then tell Git to keep the code I need it to keep. Certainly I could do that, I suppose, for all affected scripts, but I'd rather not do a "hack" if there is a more elegant way to handle it using Git.

I have done a git diff feature-branch command and copied the results in to a text doc so I could pick through it to determine what all needs the above "hack treatment", but it's BIG.

I'm not certain if there is any screenshot-type of info that would help, so none is included. Please let me know of any helpful info needed and I'll provide it with an edit to this.

Any help would be much appreciated.

UPDATE #1

Shows terminal commands during the merge process: **sitting on the "master" branch...this is what is showing after doing the "hack" on apps/account/views.py

kedmiston:ahnew kedmiston$ git merge ftr_refer
Auto-merging apps/ajax/views.py
CONFLICT (content): Merge conflict in apps/ajax/views.py
Auto-merging apps/account/views.py
CONFLICT (content): Merge conflict in apps/account/views.py
CONFLICT (modify/delete): apps/account/templates/account/refer-success.html deleted in HEAD and modified in ftr_refer. Version ftr_refer of apps/account/templates/account/refer-success.html left in tree.
CONFLICT (modify/delete): apps/account/templates/account/refer-a-friend.html deleted in HEAD and modified in ftr_refer. Version ftr_refer of apps/account/templates/account/refer-a-friend.html left in tree.
Auto-merging ahnew/urls.py
CONFLICT (content): Merge conflict in ahnew/urls.py
Automatic merge failed; fix conflicts and then commit the result.
kedmiston:ahnew kedmiston$ git mergetool

UPDATE #2

Latest thought/suspicion...is that what is getting lost in the merge from the feature branch (ftr_refer) to master is from commits in the ftr_refer history that were made prior to the date of the master commit that I’m attempting to merge to. That said, I wonder if I were to roll back master to a date in late Sept, merge ftr_refer in to it, would that allow the ftr_refer changes to come over to master correctly or not? And then, if so, how could I then reapply the commits/merges to master that would bring it back current?

Attached some screenshots of the git log command from ftr_refer (1): and master (4):

Answer 1

This won't so much be an answer as some explanations, but it's longer than comments allow.

Anytime you do a merge you are looking at joining two parts of history. You always have 3 magic values when you merge, BASE, REMOTE, LOCAL. If you were to do git checkout master followed by git merge ftr_refer then those three magic values would be set as follows

BASE=$(git merge-base master ftr_refer)
LOCAL=master
REMOTE=ftr_refer

The changesets that you are merging are represented as

git log ^${BASE} master # changes on master only 
git log ^${BASE} ftr_refer # changes on ftr_refer only 

Git provides shortcuts for that via

git log ftr_refer..master # changes on master only 
git log master..ftr_refer # changes on feature refer only

Imagine that you have a version of the views.py in the BASE version that is 1000 lines long. In master somebody goes and deletes the first 500 lines. In ftr_refer somebody else goes and modifies lines 900-1000. When you merge those together, Git is going to combine both of those changes. So you will end up with a merge views.py that is missing the first 500 lines, and has lines 400-500 modified. Git won't tell you this is a merge conflict or ask for any help in resolving this. Now, had you modified one of those first 500 lines - then yes you get a conflict (as you found).

It sounds as though somebody on master deleted some changes and you don't want those changes in your final result. Normally, I would not recommend handling this during a merge itself. Perhaps instead you want to revert those changes. If however, it is only that those changes are needed in combination with the changes from ftr_refer then you have a couple of ways to deal with it.

Start off by figuring out which commit(s) are touching that file. You might do

git log ftr_refer..master -- account/views.py

Or you could look at all the commits and list the files changes

git log --name-only ftr_refer..master

This should show you which commits deleted those lines. Perhaps consult with the author of that commit. Perhaps those lines really should be deleted. Perhaps they are bad and should be reverted. If we presume those lines only don't need to exist with the ftr_refer changes then you have some trouble. One way you could fix it would be the following.

Merge master to feature one commit at a time. So instead of

git checkout ftr_refer
git merge master 

You would do

git checkout ftr_refer
git rev-list --reverse ftr_refer..master # this will list out a bunch of shas

Process the SHAs in order. For any SHA where you want to keep the changes you would do

git merge SHA 

For any SHA where you do not want the changes you would do

git merge -s=ours SHA

Which would create merge history for the SHA without incorporating the changes.

This only works if you have an all or nothing approach to the changes on a per-SHA basis. If there is a single SHA and you want changes in foo but not bar then this will not work. You have to do those even more manually.

As to your specific idea " I were to roll back master to a date in late Sept" - generally speaking using date's isn't going to be useful here.