echurchill / CityWorld

Minecraft/Bukkit world generator
62 stars 36 forks source link

Cannot contribute due to line endings issue #17

Closed coaster3000 closed 9 years ago

coaster3000 commented 9 years ago

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

Black-Hole commented 9 years ago

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

coaster3000 commented 9 years ago

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.

coaster3000 commented 9 years ago

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

echurchill commented 9 years ago

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?

coaster3000 commented 9 years ago

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.

echurchill commented 9 years ago

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 :-(

echurchill commented 9 years ago

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: notifications@github.com To: CityWorld@noreply.github.com CC: eddie@virtualchurchill.com 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.

                  =
cmoore commented 9 years ago

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.

coaster3000 commented 9 years ago

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.

coaster3000 commented 9 years ago

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 commented 9 years ago

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. :disappointed: My apologies.

coaster3000 commented 9 years ago

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

coaster3000 commented 9 years ago

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.

coaster3000 commented 9 years ago

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.

keenerb commented 9 years ago

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

echurchill commented 9 years ago

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

coaster3000 commented 9 years ago

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.

coaster3000 commented 9 years ago

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

echurchill commented 9 years ago

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

echurchill commented 9 years ago

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.

coaster3000 commented 9 years ago

It worked thankyou! :+1: