0

I work on two machines (Mac and Windows) with git-svn. My remote repo is an svn. I use the Mac as master repo, and the Windows as a slave. So all git-svn operations are done on the Mac, and the Windows machine only "git pull" or "git push" with the Mac.

My workflow which looks like the following often puts me into the situation where I need to resolve hundreds of conflicts:

  1. I mainly work on the Mac and then let Windows "git pull" and make tests.
  2. Sometimes I need to work on Windows a bit and commit to a feature branch.
  3. Then I "git push origin" to push the branch back to Mac.
  4. Then on Mac I "git merge windows_branch" into my master branch.
  5. Finally I "git svn rebase" and "git svn dcommit".

At step 5, Here come the conflicts!! And I once spent 3 hours going through each and every conflict using "git mergetool", "git rebase --continue", "git rebase --skip", and "git rebase --abort" workflow. If I'm lucky, I can figure out all of them; but sometimes, there are just way too many of them, and worse, the rebasing goes through the same set of conflicts repeatedly as it traverses the history (git knows only changes, not files); eventually I get confused, mis-resolve some of them, and cause bigger nightmares. Some scripts I learned can help me do something like "git accept-ours" or "git accept-theirs", but this doesn't work too well with history that involves deleted files, and I still need to accept repeatedly.

This was such a nightmare to the point where I really start to hesitate to use branching-and-merging workflow. The problem remains that I don't know exactly why there can be so many conflicts. But if there are recommended workflows or practice that can help me either prevent such conflicts or easily batch-resolve, it would be great.

Thanks for you help!

kakyo
  • 10,460
  • 14
  • 76
  • 140
  • One thing I suddenly realized: I should've "git diff master feature_branch" before I merge; and also I should have first "git svn rebase" before merging. Do you agree? – kakyo Mar 15 '13 at 21:34
  • 1
    you ought to read basics about rebase and merges, everything is mixed up here. Based on your needs, you don't need rebasing at all. Also, you should be able to keep your work from getting out of hand given that you're the only person working on it, am I right? – Sébastien Dawans Mar 15 '13 at 23:16
  • Thing is "git svn rebase", i.e., the git-svn version of "svn update", is a rebase operation. That was the real problem. Anyways, I found rerere might be a solution and in general, "git pull" was the problem where I tend to forget to do a manual merge commit (I set merge option to no automatic commit). That was where it all went wrong. – kakyo Mar 16 '13 at 16:37

1 Answers1

1

I finally found the problem and will try to answer my own question here:

In my global .gitconfig I disabled automatic merging with

mergeoptions = --no-commit

But after each "git pull", I didn't actually commit the merge on my Windows slave and later pushed things upstream to my Mac master. That was where all the conflicts came from.

I think the general suggestions I got from Web regarding rebase/merge workflows are:

  1. Use "git fetch" instead of "git pull" as much as possible, so that further decisions can be made.
  2. Use "rerere" to automatically resolve repeated known conflicts.
  3. Prefer squashing small commits into a fat one before "git svn dcommit" or branch merging, using either "git rebase -i" or "git merge --squash". This will to some extent reduce the number of repeated conflicts.
  4. Create duplicate branch or tracking branch before merging or rebasing to preserve unsquashed branch history.
  5. Use "git list-files -u" to show conflicted files before merging.
  6. Before every merging operation, use "git diff branch1 branch2" before merging to avoid merging blindly.
  7. Use "git show branch..file" to view a particular file under a branch to verify against.
kakyo
  • 10,460
  • 14
  • 76
  • 140