4

I've just overwritten my co-workers code by merging FETCH_HEAD and getting my more recent changes instead of his. I want to revert to before the merge, then do the merge forcing his changes to be accepted where he touched the file, but getting my merges where there isn't any other changes.

My git log (created with l2*) looks like this now :

*    3f6308d - (HEAD, master) Merging changes (confliect in PriceListForm.java.. was a formatting change only (Sun Dec 29 09:07:27 2013) <Gre
|\  
| *  283c00c - Changing wv reports to be separated by changes in prices according to received_date rather than lab_number. (Thu Dec 26 19:39:
| |
| *  4846bf2 - Merge branch 'master' of ssh://git-pacce@free1.projectlocker.com/pcs.git (Wed Dec 25 17:49:19 2013) <jpjones>

When I performed the merge, there weren't any conflicts in those files, it just took my changes instead of the less recent changes by jpjones.

Basically I want to redo 3f6308d, but allow jpjones changes to take precedence. This StackOverflow Answer seems to be relevant to what I want to achieve, but I'm not sure and was hoping for some clarification.

* git l2 is alias l2 = log --graph --all --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset' --abbrev-commit --date=local
Community
  • 1
  • 1
Greg
  • 458
  • 1
  • 5
  • 15

1 Answers1

0

Considering you haven't pushed your faulty commit yet, you can safely reset your HEAD to the commit before:

git reset --hard HEAD^

(Make sure you don't have work in progress, like private files or files added to the index, because both the working tree and the index would be reset to the HEAD^ state)

This is what the answer you mention suggests.

But after that, you need to make sure your coworkers' changes are taken during the merge your are about to do again.
See if a theirs "merge strategy option" works better.

git checkout yourBranch
git merge -X theirs theirBranch

However, I suspect it would work only for solving conflicts (concurrent modifications in a file).
If you have made more recent changes, those would still be in the resulting merged HEAD.

If that is so, try following the recipe in this answer, which forces a merge to your branch, and then reset yourBranch to theirBranch, before moving HEAD to the merged commit done before.
Then end result should look like what you are after.

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • This doesn't solve my problems entirely, but it answers the questions and I'll certainly do things differently in the future. The problem now is that as you expected, the "theirs" strategy doesn't quite for this case and we are committing everything to master (no topic branches) – Greg Dec 30 '13 at 20:17
  • @Greg I suspect http://stackoverflow.com/a/4969679/6309 that I mention at the end should be more precise. – VonC Dec 30 '13 at 20:45
  • Everything is on master, so using different branches to merge doesn't make sense to me, in this case. I'm not sure if I can do the same with revisions instead of branches. – Greg Dec 31 '13 at 01:29