Whitespace/Line endings even with .gitattribute file

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?

1 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.

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!

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Piotr Plewa
Published Dec 27, 2017 in Bitbucket

Recipe: Deploying AWS Lambda functions with Bitbucket Pipelines

Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda&nbsp...

1,751 views 1 5
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you