0

In our git repo our files sometimes end up with additional carriage returns at the end of the line. When I view the files in vim I see;

<?xml version="1.0" encoding="utf-8"?>^M
<Root>^M
    <Child/>^M
</Root>^M

These extra ^M will be on every line in the file. This causes problems when we merge because the other side of the merge will not have the additional ^M and we get many merge conflicts. Passing options to ignore white space to git merge doesn't seem to help, it still conflicts on the whole file.

We use git config core.autoclrf true.

I need two things;

  1. How do a search for all of these ^M in my repo? Such that I can use some git ls-files | grep <filter here> | sed 's/^M//' to get rid of them.
  2. How do I identify how they're being introduced?
Adam
  • 4,180
  • 2
  • 27
  • 31
  • 1
    As for **1**; `git ls-files | xargs dos2unix` ought to do it. – Biffen Sep 21 '18 at 12:44
  • @Biffen thanks, do I need to consider any binary files with that? – Adam Sep 21 '18 at 12:46
  • I think this may be a duplicate of [this](https://stackoverflow.com/questions/15641259/how-to-normalize-working-tree-line-endings-in-git). – Adam Sep 21 '18 at 12:46
  • 1
    `dos2unix` will just skip binary files (at least my version of it will, you might want to check yours). – Biffen Sep 21 '18 at 12:48

2 Answers2

0

I resolved this by using unix2dos (I'm on windows) as @Biffen suggested and also the answer in the linked question here.

Adam
  • 4,180
  • 2
  • 27
  • 31
0

The answers to How to normalize working tree line endings in Git? are great for fixing up new commits. (See both the accepted one, and the modern Git 2.16-or-later git add --renormalize trick.)

To deal more easily with old commits, use the renormalize extended-option: git merge -X renormalize [other options you want if any] branch. This applies your current .gitattributes setting to all three versions of each file that is to be merged.

torek
  • 448,244
  • 59
  • 642
  • 775
  • I don't know why, it might be because I don't _have_ a `.gitattributes` file, but `-X renormalize` didn't help compared to just running `git add --renormalize .` on each branch before merging. – Adam Sep 21 '18 at 22:51
  • 1
    You do in fact need a `.gitattributes` file to make the renormalize switch do something. It's really doing both CRLF *and* any clean/smudge filter operations, which are actually kind of the same thing inside Git: CRLF hacking is just a built-in clean/smudge filter. – torek Sep 21 '18 at 22:58