|Re: [jgit-dev] [cross-project-issues-dev] EGit / line ending problems with simrel repo|
I doubt this conclusion is correct. You can tell git which files (extensions) are binary via .gitattributes
On 16/08/2012 12:32 PM, Ed Willink wrote:
After a quick Google it seems GIT does not normalize Windows line endings unless autocrlf is set true, which may have other bad effects like normalizing binary files too.
So if we use the default autocrlf=false we are left with the bad alternative; get all CR-LF producing tools fixed, which is difficult since Eclipse's default line-endings on Windows are CR-LF, so CR-LF production is correct.
I did a quick scan of my Workspace for CR-LFs; Eclipse locked up with over 65000 search matches.
After a kill and restart and a search in a single project, I had two rogue files; both manually edited Java files. It seems that once you get a CR-LF from somewhere, JDT's indentation preservation also preserves line termination and once there are some CR-LFs, JDT thinks you like them.
So until EGIT acquires CVS's binary flag our only solution is to regularly manually remove all CR-LFs that have leaked in somehow.
On 16/08/2012 10:44, Eike Stepper wrote:
Am 16.08.2012 11:25, schrieb Ed Willink:
We agree. I was just elaborating the bad alternative.Hi
My suspicion is that the problem is in the comparison tooling.
The files in the repo seem to be normalized to LF line endings, but some Windows tooling creates CR-LF; some tools can
be fixed via Bugzillas but it's a losing battle.
I totally disagree. All these tools have been working fine with all other version control systems.
And the false positives in the staging view appear with no comparison tool being involved. And it's impossible to getThere is a comparison. EGIT must do a file compare to determine whether the file is changed. If you edit a file and edit
rid of them by means of the tool (EGit) that has created them.
it back again, the file disappears from the staging view, so EGIT must be using content rather than timestamp to detect
Oh, of course I know that. I *guess* it's done with the SHA1 digests of the files' contents because they're needed anyway.
Back to the top