Eike Stepper skrev 2012-08-16 06.52:
Hi,I'm working on a Windows box and my clone of org.eclipse.simrel.build marks files dirty that I have not touched myself. Currently this is the case for: mdt-ocl.b2aggrcon webtools.b2aggrcon My Git system config file contains: [core] autocrlf = true Egit displays no values for the *system* configuration in the properties view (UI bug? core bug? any bug??). Egit displays a duplicate value ("[true][true]") for the *global* configuration in the properties view (UI bug? core bug? any bug??).
That's wierd, please create a bug report with the config files. Also verify that EGit sees the system config file
Hard reset with EGit does nothing (bug?). Double-click on the dirty files in the staging view opens a Compare editor with no changes, both with or without "Ignore Whitespace Changes" (bug?). The only way for me to solve this is very strange: I have to open a native Git shell and just execute "git status". One would think that's a pure read access command but mysteriously it removes the bogus changes from my workspace (or the EGit index?).
git status unsmudges the index if it looks like there may be a possible diff, but then there isn't one. Both git status and git diff can modify the index. JGit does not do that at the moment.
The EGit team tries to blame the Platform Compare framework ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=361503 ), which I can hardly believe. At no time in my 30 years computer life I had such fundamental problems with line ending characters (which I believe are the root cause). This all started with the advent of EGit.
I'm not trying to "blame" the platform team. I'm suggesting that the option to ignore line-endings, when there is such diffs, belong there. That's based on how I interpreted the comments in the bug. The bug report itself wasn't specific enough. Hard evidence is neeeded when there are many possible reasons for a problem. With the information you provide now (reference to a repo) there might be more to it. Could you open a new bug and include the URL's to the problematic repo, including a problematic commit id (I'm assuming todays master is such). That makes the bug report less ambigous. I fixed a bug in JGit the other day that might improve things (just speculating since a bug reported files being different even when they weren't. https://git.eclipse.org/r/#/c/7231 should be in the nightly build by now. The fix is not for crlf per se, so there is just a "migth" improve things.
Am I the only one with these problems, so that I have to revist my config again (which I've done a hundred times already)?
Windows isn't my primary platform and my Windows repos have CRLF line endings, which unfortunately limits the dogfooding here. My windows repos are actually Clearcase clones (still) and I'll get problems with round-tripping if I normalize them. And, also there is no contract on this feature and so priority is low. Eventually I'll need autocrlf myself though. In a way the evolution of autocrlf for egit/jgit is similar to how it was developed for Git. It took quite a while since most Windows feedback only came on released code, whereas most other features get feedback on patches and nightly builds. -- robin _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
