git merge: filter files to avoid silly conflicts (like whitespace or case changes)

Question

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.

Asafoetida

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. – Stereotyped

Note: git merge won't be bothered by case changes anymore, from git 2.0.1+: see my answer below – Unleavened

possible duplicate of Merging without whitespace conflicts – Medici

Answer 1

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

Devindevina

See documentation: kernel.org/pub/software/scm/git/docs/v1.7.4/git-merge.html – Asafoetida

This seems a good solution except for rebase and case change in Ada – Asafoetida

@user: rebase should take strategy options as well – still not solving the case change case of course – Devindevina

Answer 2

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.

Unleavened

The question was more about case changes in file content itself. But that's still good information. – Asafoetida