Whitespace/Line endings even with .gitattribute file

Question

Our development shop is using Stash and migrated from a TFS configuration several months ago. We've noticed a pervasive issue with whitespace and line endings (showing entire files changed) even though we have .gitattributes files in every repository *AND* we have everyone using the same line ending handling files. We're entirely windows-based with everyone using SourceTree, Github for Windows, or TortoiseGit for the most part. Some products are having enormous issues and others don't have any issues at all.

Anecdotally, I'm told the people who suffer the worst are those who are doing a lot with feature branches. Like one of our products often has 3 - 5 feature branches in development at any point in time to be merged at some point in the future (i.e. we do dev work for a feature that will be implemented at some arbitrary point in the future or not at all dependent on how it turns out).

All our machines are Windows 7 64-bit.

We have everyone configured with:

git config --global core.autocrlf true

Our stock .gitattributes file is the following and is in the root of every single repository:

* text=auto

*.doc diff=astextplain

*.DOC diff=astextplain

*.docx diff=astextplain

*.DOCX diff=astextplain

*.dot diff=astextplain

*.DOT diff=astextplain

*.pdf diff=astextplain

*.PDF diff=astextplain

*.rtf diff=astextplain

*.RTF diff=astextplain

*.bmp binary

*.gif binary

*.jpg binary

*.png binary

*.ascx text

*.cmd text

*.coffee text

*.config text

*.cs text diff=csharp

*.csproj text merge=union

*.css text

*.cshtml text

*.htm text

*.html text

*.htm text

*.js text

*.msbuild text

*.resx text merge=union

*.ruleset text

*.Stylecop text

*.sql text

*.targets text

*.tt text

*.txt text

*.vb text

*.vbhtml text

*.vbproj text merge=union

*.xml text

*.xunit text

*.sln text eol=crlf merge=union

Can anyone shed any light or explain why we might be having whitespace issues?

Bryan Wolf1 · Answer

Hello Gustavo,

Thanks for the thoughts. I am thinking this is possibly related to git, too, but I am not sure. I haven't seen the pervasiveness of broken line-endings with .gitattributes files like I'm seeing here, so I wanted to come here first.

The only thing that comes to mind immediately is that these are pretty much every file - from .csproj xml files to .cs files to ancient .pas (pascal) files. They're all always on Windows machines, so it could be that we have to identify all of our files with .crlf but I'd think that would be something that would show up all over the place. It might be a solution, but it's challenging to think of why that would be specific to our use case.

I did go through the formatting & whitespace whitepaper there, before, in trying to resolve this and I wasn't really finding anything. The only interesting thing I don't seem to find a lot of is that our Git Stash machine is Windows I believe. Could there be some setting we need to do server side?

As an example, one of our users is working on really old Delphi files with an appropriate .gitattributes file for that project. If they are on branch A, which has the .gitattributes file, and delete a bunch of files and then go to branch B, which has the .gitattributes file and the .pas files, they'll end up with a bunch of unstaged line ending changes. Unfortunately I don't have any screen shots of this yet. The only solution is to either commit the changes or, interestingly, delete the entire repository and re-clone it down. I haven't found a good command to reset the index, but git rm --cached doesn't help either. The really interesting thing is that every project with more than 1 user has examples of this coming up.

I have faith there's an answer somewhere - I've worked on a myriad of C# and other projects on Windows with people on Linux and had fewer line ending issues. There's gotta be something we're missing.

Thanks again for your help!

gustavo_refosco · Answer

Hi Bryan,

Before presenting my findings so far I'd like to point that, as far as I could test, this is related to Git and Stash is merely reproducing what's also seen when acessing the repository directly.

Talking first about line endings, depending on which OS you are working, or even the tool you are using, line endings are made differently (I believe you already know that, as you've set the core.autocrlf setting). For example, before applying any setting to Git, I was able to have two results (using a .xml file as example):

* If I edited my .xml using a text editor like, for instance, TextMate, and inserted a line in the end by using the Enter button (carriage return), the line isn't shown in Git/Stash.
* The behavior changes when using vi in the command line. When inserting the lines using it, they are shown in Git/Stash (e.g. I pressed Enter 2 times by the end, 2 empty lines were shown).

I was able to "fix" this (i.e. having the line being shown independent of the application used to edit the file) by setting another option in the .gitattributes which is described at https://help.github.com/articles/dealing-with-line-endingsunder Per-repository settings:

# Declare files that will always have CRLF line endings on checkout.
*.xml text eol=crlf

The only thing I found about the option above is that it "ignores" the first CRLF so, for instance, if you have pressed Enter 4 times by the end of the file, Git/Stash will show only 3 lines (this is checked outside Stash, so it is related to the behavior of Git).

Regarding the whitespaces, I couldn't understand exactly what's happening currently for you, but I think the settings shown at http://git-scm.com/book/en/Customizing-Git-Git-Configuration#Formatting-and-Whitespacemay be helpful.