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 suspect that some of EGIT's comparisons are failing to perform a
pseudo-commit to normalize the line endings before performing a
comparison.
[EGIT has no obvious counterpart of CVS's binary flag, so how does
it know which CR-LF byte pairs it is safe to normalize?]
Regards
Ed Willink
On 16/08/2012 09:17, Ed Merks wrote:
David,
Comments below.
On 16/08/2012 9:53 AM, David M
Williams wrote:
Eike (and Ed)
I'm the last person to be
giving good advice about Git and EGit ... but that has never
stopped me before :)
I always follow the advise in
the Platform's workflow,
http://wiki.eclipse.org/Platform-releng/Git_Workflows#Configuring_the_repo
where they suggest
"Make sure that you set core.autocrlf = false
and on Windows core.filemode = false.
That's just not an appropriate suggestion. The basic premise is
that EGit doesn't work so do what it takes to avoid hitting the
problem because Egit can't handle it. If git can handle it
properly then so can EGit, if there's a focus on actually fixing
the problems.
If you use EGit to clone the
repository then this is done automatically for you. "
So ... have you tried autocrlf
= false? I think everyone should, no?
No.
While there's obviously bugs
and problems in this area, I think our simple goal is to
always use LF (Unix EOLs) in all cases ... in the repo, in the
working directory, and everything in between.
There are tools on windows (generator tools for example) that will
use Window's conventions. Their results will tend to sneak into
the repo and cause other problems, i.e., someone on Linux will end
up seeing Window's conventions.
One complication is that
sometimes (I think) EMF Serialization does not use the project
preference for EOL when serializing the model.
EMF's generator generally tries to use the convention of the file
it's updating or use the workspace preferences for new files. But
the generator's are Eclipse aware. The serializer knows nothing
about Eclipse and isn't even in a position to see the conventions
used by the actual input.
Only a few
operations cause the whole model to be serialized, but some
do, and then, I've seen, in the past, have the files change do
to EOL problems. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=325145) (The bug was closed as invalid
since a) no one else complained :) and b) didn't seem easy to
fix.
Accordingly we've said, in the
past, if you see files change for no good reason, and you can
see nothing of substance changed, go ahead and commit them.
Oops, you just committed the wrong line endings...
You may be
correcting a previously incorrect formatting or EOL and
feedback in the past has been people find that less confusing
(even though it may mean they may lose a comment or their
favorite formatting).
Or you may be committing inappropriate line endings into the repo
and then cause problems for the next guy on a different platform.
I hope others have better
advice, but that's the best I have.
This was never a problem with CVS. It's not a problem with git.
It's mostly fixed in EGit. Please let's fix the small remaining
problems.
Thanks,
From: Eike Stepper <stepper@xxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx,
Date: 08/16/2012 12:53 AM
Subject:
[cross-project-issues-dev]
EGit
/ line ending problems with simrel repo
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
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??).
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?).
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.
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)?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5203 - Release Date:
08/15/12
|
