2012/8/16 Ed Merks <ed.me...@gmail.com> > Ed, > > I doubt this conclusion is correct. You can tell git which files > (extensions) are binary via .gitattributes > > https://help.github.com/articles/dealing-with-line-endings > > I've not had problems with binary files (images for example) getting > mangled. >
JGit doesn't support gitattributes yet, that's why EGit doesn't know the difference between ASCII and binary files. There is a pending draft [1] since a long time but it seems Marc didn't find the time to continue on that. Tasktop recently said they intend to work on this feature later this year [2]. [1] https://git.eclipse.org/r/#/c/1615/ [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372 > Regards, > Ed > > > > On 16/08/2012 12:32 PM, Ed Willink wrote: > > Hi > > 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. > > Regards > > Ed Willink > > On 16/08/2012 10:44, Eike Stepper wrote: > > Am 16.08.2012 11:25, schrieb Ed Willink: > > Hi Eike > > 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. > > We agree. I was just elaborating the bad alternative. > > > Good ;-) > > And the false positives in the staging view appear with no comparison > tool being involved. And it's impossible to get > rid of them by means of the tool (EGit) that has created them. > > There is a comparison. EGIT must do a file compare to determine whether > the file is changed. If you edit a file and edit > it back again, the file disappears from the staging view, so EGIT must be > using content rather than timestamp to detect > changes. > > actually it's using both as also c git does, jgit tries to use meta data as much as possible since lstat is a lot faster than computing SHA1 of the content. Though In some cases it has to do that in order to provide correct results > Oh, of course I know that. I *guess* it's done with the SHA1 digests of > the files' contents because they're needed anyway. > > I'll try to implement what Gunnar suggested in [3] in order to improve EGit's line break handling. Though full handling of autocrlf requires jgit support for gitattributes. [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=361503#c9 -- Matthias
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
