[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [egit-dev] [cross-project-issues-dev] EGit / line ending problems with simrel repo
- From: Matthias Sohn <matthias.sohn@xxxxxxxxxxxxxx>
- Date: Thu, 16 Aug 2012 23:23:14 +0200
- Delivered-to: email@example.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1wQcjoTIYgprKdD3RtMogSMvl3wXmwGBqDqGlFAy8ro=; b=FYIuX6jvksfHj62WyOPAMc6zn6bSFj8Mhs1LqfKHk6gIpTA0w8Q1x9zLbWS36GzuY4 bJp+R7hLQ0CDJNpjGTbXh4DDHU5hj445h/ZmLMLL6tZKax/0etYOV3WFpgSNWphcWIQj c5IqszcZOs8wydETxwQLYDdKCETgy5NucrB+r3IEWD/zv8K7ONlunYQxLLcaNI8502R9 UCCKe5n+Gw3+bGxKvkHN0fi7OF+B0iJi23Psg+jWAM+u8iUHEnEAJoDjyjPyqOW+Di89 zecpFSc4hui95GTdUaWFhtkV81E20TvSfBvA/nVK+aQqnpOExdV+dXUG8edBUnI1LYVV hIdw==
I'll try to implement what Gunnar suggested in  in order to improve
2012/8/16 Ed Merks <ed.merks@xxxxxxxxx>
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  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 . Â
On 16/08/2012 12:32 PM, Ed Willink
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.
ÂÂÂÂÂÂÂ Ed Willink
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.
My suspicion is that the problem is in the comparison
The files in the repo seem to be normalized to LF line
endings, but some Windows tooling creates CR-LF; some
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 get
There is a comparison. EGIT must do a file compare to
determine whether the file is changed. If you edit a file and
rid of them by means of the tool (EGit) that has created
it back again, the file disappears from the staging view, so
EGIT must be using content rather than timestamp to detect
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.
EGit's line break handling. Though full handling of autocrlf requires
jgit support for gitattributes.