7

I'm currently inside a very complicated merge in git, and I have many conflicts. The conflict is about two Ada source files.

I would like to make a merge that would ignore both whitespace changes and case changes (as the Ada language is case insensitive). Do you know if there is a way to tell git to ignore some kind of changes before a merge ?

My solution is currently to run the GNAT pretty print on both branches before the merge, but if there was a common solution included in git, that would help me a lot.

svick
  • 236,525
  • 50
  • 385
  • 514
Mildred
  • 3,887
  • 4
  • 36
  • 44
  • 1
    It'd probably be easier to standardize internally case and whitespace anyway to avoid this problem _next_ merge; incidentally some tools such as xxdiff can make cleaning up merge conflicts a lot easier. – sarnold Feb 01 '11 at 10:35
  • Note: git merge won't be bothered by case changes anymore, from git 2.0.1+: see [my answer below](http://stackoverflow.com/a/24978770/6309) – VonC Jul 27 '14 at 07:18
  • possible duplicate of [Merging without whitespace conflicts](http://stackoverflow.com/questions/9776527/merging-without-whitespace-conflicts) – jww Aug 25 '14 at 18:50

2 Answers2

4

from the release notes of git 1.7.4:

* The "recursive" strategy also learned to ignore various whitespace changes; the most notable is -Xignore-space-at-eol.

I don't know if there is a strategy to ignore case changes though

knittl
  • 246,190
  • 53
  • 318
  • 364
0

Regarding the case issue, which is problematic on case insensitive OS during a merge, this won't be an issue with git 2.0.1+ (June 25, 2014).

See commit ae352c7f37ef2098e03ee86bc7fd75b210b17683 by David Turner (dturner-tw)

merge-recursive.c: fix case-changing merge bug

On a case-insensitive filesystem, when merging, a file would be wrongly deleted from the working tree if an incoming commit had renamed it changing only its case.
When merging a rename, the file with the old name would be deleted -- but since the filesystem considers the old name to be the same as the new name, the new file would in fact be deleted.

We avoid this by not deleting files that have a case-clone in the index at stage 0.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • The question was more about case changes in file content itself. But that's still good information. – Mildred Aug 22 '14 at 08:02