Hi John
Thanks. Your recommendations make a lot of sense. I'll zap Unix (and
UTF-8) all round.
However, setting the workspace preference seems unnecessary. The
Project preference is imposed on everyone, so its uniform. The
workspace preference is uncertain so I prefer not to change it for
non-cosmetic effects since the Eclipse defaults are the only setting
that another workspace is likely to share.
Regards
Ed Willink
On 16/08/2012 16:30, John Arthorne
wrote:
For what it's worth,
we settled on the
following approach for the Eclipse top-level project (always use
Unix delimiters
and use Eclipse settings to control it):
http://wiki.eclipse.org/Platform-releng/Git_Workflows#Dealing_with_line_terminators
Also note you can select an
entire project/folder/etc
and do File > Convert Line Delimiters To > Unix to make
sure you
are in a consistent state.
John
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.
>
> Oh, of course I know that. I *guess* it's done with the
SHA1 digests
> of the files' contents because they're needed anyway.
>
> 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
>
>
> -----
> 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
>
>
_______________________________________________
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
|