29

Lets assume that we have one development branch 'A', and two sub branches 'B1' and 'B2', (both taken from A). Lets say that you run a format code command (in our case ReSharper's cleanup code) on the entire project in B1 and B2.

Now, when we try to merge B2 into B1, Git will report conflicts on all files in the project (quite a large number in our case). When looking closer at each conflict, it seems like Git thinks theres a conflict even though the exact same change was made in both B1 and B2(?)

Is there a way, custom driver/git attribute etc that will make a Git merge operation not report a conflict if the files in B1 and B2 are exactly the same?

Maybe I've got it wrong, maybe it is a whitespace/line ending issue (eg different line endings in B1 and B2) in which case I can find the solution here on stack overflow.

CharlesB
  • 86,532
  • 28
  • 194
  • 218
Emil G
  • 1,211
  • 1
  • 14
  • 26
  • 1
    you can inspect conflicts by opening the files in an editor, you'll be able to see why git sees conflicts – CharlesB May 11 '12 at 09:58
  • 2
    How much work other than the refactoring was performed in these branches? I can't speak for Git specifically, but generally, you'd do this only in one branch, merge the changes to the parent, then have the second branch pick up that refactor. – OrionRogue May 11 '12 at 10:04
  • Did you try to use kdiff3 as mergetool in git? It usually can handle those trivial conflicts on its own. – vhallac May 11 '12 at 11:56
  • @OrionRogue: Both B1 and B2 have a pure 'refactor code commit', ie no other work was made in this commit. Of course there are other commits ion each branch which might lead to 'real' conflicts. I guess I could eg cherrypick the 'refactoring commit' from B1 and put it into B2 but then the files which are exclusively in B2 wont be refactored. – Emil G May 11 '12 at 13:16
  • 3
    @EmilB, I have a sneaking suspicion that you're going to have to weigh the cost/benefit of having one branch win, then refreshing, or manually merging all those files as one large merge activity. If the actual changes between the two branches isn't ACTUALLY a lot, you might be better off with the first option. – OrionRogue May 11 '12 at 13:35
  • It seems like a lot of the reported comments is however due to inconsistent line endings. Thanks for all the great input. – Emil G May 11 '12 at 16:05
  • 2
    This question explains, how to merge ignoring white spaces: http://stackoverflow.com/questions/861995/is-it-possible-for-git-merge-to-ignore-line-ending-differences – Boris Brodski May 17 '13 at 07:13

1 Answers1

2

Yesterday I had similar issue after a lot of cherry-pick from (and to) a side branch where I after merged with my main branch. A lot of conflicts with identical change. I solved this with a merge strategy:

git checkout main-branch
merge --no-commit -s recursive -X ours side-branch

you can change "ours" to "theirs". Be careful because all conflicts are automatically solved choosing "ours" or "theirs" side. In my case I had few mis-merges due to this, and I fixed manually. See others interesting options of merge strategies here: https://www.kernel.org/pub/software/scm/git/docs/git-merge.html

You can also try to use a rebase (in my case it did not work well because the branchs were too different and I had a new conflict in each new rebase interaction). See this: http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/

Felipe
  • 16,649
  • 11
  • 68
  • 92