Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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,
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.  ( (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

I hope others have better advice, but that's the best I have.

Thanks again and let's see...



Back to the top