2

I don't know if that's a common problem. Most of the times that we pull a CSS file from our development repo, GIT conflicts with the current file, entirely merging the two files by putting the ">>>" and "<<<" markers at the very top and bottom, and a "===" marker separating them.

We tried some different indentation, and that helped a little, but there's no success at all. We don't have problems with any other file type, most of them are PHP and JS code, in this case.

If that helps, we have set all the text editors on production to use CRLF.

Thanks.

philant
  • 31,604
  • 11
  • 64
  • 107
vmassuchetto
  • 1,459
  • 18
  • 41

2 Answers2

5

This is usually due to an automatic conversion of some kind.

Could you try and set config autocrlf to false in all your git (dev and prod)?

That way, no automatic conversion is performed, which helps removing that issue causing potential merge conflicts?

Do you also have some whitespace setting which could introduce some automatic modification?

Note: starting git 2.8+ (March 2016), merge markers will no longer introduced mixed line ending (like LF in a CRLF file).
See "Make Git use CRLF on its “<<<<<<< HEAD” merge lines".

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
3

The culprit is the CRLF... If some of the boxes are windows, then automatic CRLF conversion will result in those boxes storing the files in "unix" format, even though in your cases, the unix (and mac) boxes are storing them in "dos" format.

The solution is to either tell everybody to use "unix" format, which is the typical custom with git projects - and allow windows users to use "dos" format because git (particularly msysgit) will automatically convert by default.

Or continue using CRLF (Probably the better idea here), and tell the windows users to STOP using autocrlf or even safecrlf.

Arafangion
  • 10,402
  • 1
  • 34
  • 69