Having the .gitattribute text set to auto causes some issues on certain operating systems.

On windows for example that uses CRLF will cause git to show changes that don't really exist. Attempting to commit may cause issues and attempting to force LF does not work due to .gitattribute overriding this setting.

You may see some questions and answers about it on the stack exchange site

Issue is on this Line
Blamed on commit c09649c

EDIT 2: This issue occurs on fresh installs on other computers as reported by @keenerb

You could use http://code.google.com/p/tortoisegit/ on Windows.

That is completely irrelevant to the issue.

Its a pain to fix manually and once I manage to do so. I will submit a pull request on the issue. This is something that could bar some contributors that do not know how to operate git as efficiently as some devs.

The biggest problem with this kind of issue is that if its not fixed properly. It will show back up from a simple branch switch.

I am unable to fix this problem myself. As many times as I fix it. The solution comes up as basically touching every single file making it look like i contributed 100% of the code.

I doubt that would look nice in a pull request..

I didn't create the file, either Eclipse or eGit did. I don't think I have ever intentionally touched it.
Date: Tue, 2 Dec 2014 20:26:53 -0800
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: [CityWorld] Cannot contribute due to line endings issue (#17)

Tell the truth I am not entirely sure what will make that work correctly. I have attempted that but it makes the effects linger until its all recommited.. (Every file acts as if they were just deleted and completely rewritten.)

I have never seen git act this way whenever I do development. (Then again I never have used a .gitattribute file)

—
Reply to this email directly or view it on GitHub.

                  =

I have no problem making the change and checking in everything again. It won't be the first time I have had to do this to get around a Gitism. So if I am reading all of this right you want me to make the change to .gitattribute file (specifically you want me to comment out the "* text=auto" by putting a # in front of it). Right?

To tell the truth I am not entirely sure what will make that work correctly. I have attempted that but it makes the effects linger until its all recommited.. (Every file acts as if they were just deleted and completely rewritten.)

I have never seen git act this way whenever I do development. (Then again I never have used a .gitattribute file)

NOTE: My next reply will be a lot later. Bed and work / school tomorrow.

Mind you after reading https://help.github.com/articles/dealing-with-line-endings/ I am not sure if I really understand which way this stuff is supposed to work. I use Git, I don't claim to be an expert.

If there is an expert out there who can tell me what needs to be done... great
Or wants my permission to fix it all and make everything happy... that is great too! :-)

I really hate EOL issues like this... why can't we all get along :-(

Huh - interesting. The github client for windows adds that file automatically when you make a new repo with it. I'm sure it's not the only client that does, but this looks like the same file.

I hate to say 'works on my box' here, but I think it may be an issue with your git client. I test my code (and make commits here and there) on windows, osx, and linux, and freebsd and we've never had this issue. It might be worth a look into the client config on your machine.

This is one of those issues that should never be an issue - git (usually) just silently does the right thing.

I would never use github client. Its bloated and does not have the things I need.
I will only ever use raw command line or the built in gui.

Only third party i would use is git extensions or sourcetree.

Anything else. I would test but not use at most..

EDIT: @cmoore it is not a problem with my client. My client is configured correctly. As a matter of fact that file will override client configs if its present.

Deleting the .gitattribute fixes the issue on my side completely. However I would not know what would occur on other platforms. I rather not submit a pull req for that just for that file removal. Also would rather look into other options for a fix before resorting to that. If this file is actually needed.

@cmoore Well then suggest the proper config. Don't assume its poorly configured because other projects state the configs I have as a requirement for contribution.

I really don't want this to turn into some kind of war... I just want a solution. Locally or repo based. Either one will be fine. I just don't want to have to use the solution EVER time i want to checkout the repo.

If I had to guess, I'd say at some point you configured git to force line endings one way or another. It's almost certainly the case since the .gitattributes is configured to do the right thing and your config seems to be squashing that. reference

I get that you are confident that your git config is correct, the problem is that all of this says that it's not, and your poorly configured client is not this project's problem.

I'm sure you wouldn't suggest that all of these projects are doing it wrong.

edit:

and your poorly configured client is not this project's problem.

That sounds a lot more dicky than I intended. 😞 My apologies.

About earlier comment about git doing things silently the correct way..

I entirely agree. I have no clue why this is happening as it never happens on any project I have worked with. I don't even remember seeing a .gitattribute file in those projects. (I may be wrong I have not touched them in a while)

When I first checkout the repo. It says that EVERY file has a change. Forcing a reset does nothing. Re cloning the repo still shows every file has changes across the entire project.

Edited the main post about my current config. The issue might not be the repo however can't eliminate that possibility yet. This is a lone instance of an issue so far.

I put strike through on old stuff.

Fresh Sourcetree install on Windows 8, I can verify that cloning this repo results in every single source file being marked "unstaged".

May I ask what change are you thinking of contributing? I have to admit I am curious. Is it still the plot type API?

Sorry for the long delay I have not been home to reply.

I would like to get additional methods adding to the api and possibly fix up some of it.

This issue might be caused by the fact .gitattributes was added midway through development.

So that would explain why there is no proper fix unless you recommit everything...

github help article on dealing with line endings

I will attempt what the article says to do sometime this weekend. Monday, worst case. :-)

It worked thankyou! 👍

Ok I did what it said to do. Something happened, it will be up to you to say if it fixed the problem you were seeing.