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:
*.cs text diff=csharp
*.csproj text merge=union
*.resx text merge=union
*.vbproj text merge=union
*.sln text eol=crlf merge=union
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):
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.
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!
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 ...
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot