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 
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

Back to the top