|Re: [cross-project-issues-dev] EGit / line ending problems with simrel repo
Am 16.08.2012 09:53, schrieb David M Williams:
Eike (and Ed) I'm the last person to be giving good advice about Git and EGit ... but that has never stopped me before :)
Thank you ;-)
I always follow the advise in the Platform's workflow, http://wiki.eclipse.org/Platform-releng/Git_Workflows#Configuring_the_repo where they suggest "Make sure that you set *core.autocrlf = false* and on Windows *core.filemode = false*. If you use EGit to clone the repository then this is done automatically for you. " So ... have you tried autocrlf = false? I think everyone should, no?
The repo-level config shows core.fileMode=false.I find it hard to believe that I'm supposed to switch off line ending conversion on Windows. Wouldn't that make the problem worse?
While there's obviously bugs and problems in this area, I think our simple goal is to always use LF (Unix EOLs) in all cases ... in the repo,
in the working directory,
I disagree. If I had invented Windows I probably wouldn't have chosen a line ending convention different from all other platforms. Obviously nobody had asked me :P
Now that Windows has this odd convention, most Windows tools use it properly. And why not?! All other source control systems can also properly handle and convert it appropriately. Only Git (EGit??) produces fundamental problems. I wish I just wouldn't have to think about it at all. It's obviously a problem that has to be solved in this particular tool.
and everything in between.
You're probably referring to the staging index. I'm not so sure about that one because I'm not a Git expert. But I do have the feeling that the index is a major part of the evident problem.
One complication is that sometimes (I think) EMF Serialization does not use the project preference for EOL when serializing the model. Only a few operations cause the whole model to be serialized, but some do, and then, I've seen, in the past, have the files change do to EOL problems. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=325145) (The bug was closed as invalid since a) no one else complained :) and b) didn't seem easy to fix.
Ed Merks will probably comment on this specific argument. On the other hand I have the impression that (E)Git's merging and rebasing creates these dirty files that I didn't touch otherwise.
Accordingly we've said, in the past, if you see files change for no good reason, and you can see nothing of substance changed, go ahead and commit them. You may be correcting a previously incorrect formatting or EOL
It can't be the responsibility of client-side tools to accidentally cure problems in the repo!
and feedback in the past has been people find that less confusing (even though it may mean they may lose a comment or their favorite formatting). I hope others have better advice, but that's the best I have.
Thanks again and let's see... Cheers /Eike ---- http://www.esc-net.de http://thegordian.blogspot.com http://twitter.com/eikestepper
Back to the top