Re: [platform-dev] CRLF Problems

2019-09-24 Thread Ed Merks

Dani,

I added this to my Installation.setup in the Platform SDK IDE:


http://www.omg.org/XMI;
    xmlns:setup.p2="http://www.eclipse.org/oomph/setup/p2/1.0;
    label="Git Bash">
  
  https://download.eclipse.org/oomph/updates/nightly/latest"/>


So that answers the question of what to install and where it comes from.

The new action is only in a nightly build right now and is in this 
plugin for lack of a better home.


With this installed, the context menu of a Repository (in the Git 
Repositories view) will have additional action, including "Fix CRLF".  
It's rather a crude tool, but effective.


Regards,
Ed


On 24.09.2019 14:57, Daniel Megert wrote:

Hi Ed

Where is the tool?

Dani



From: Ed Merks 
To: "Eclipse platform general developers list." 
Date: 24.09.2019 08:45
Subject: [EXTERNAL] [platform-dev] CRLF Problems
Sent by: platform-dev-boun...@eclipse.org




Guys,
The platform's Git repositories are rife with text files that have 
been committed with CRLF rather than LF. These things generally lead 
to totally confusing problems in EGit where files are shown as dirty 
with no apparent actual differences. This is of course a barrier to 
entry for our contributors.  Worse still, the problems are really 
quite hard to fix.  Previous attempts to fix such things indicate that 
it's all to easy to "fix" them incorrectly, e.g.,

_https://git.eclipse.org/r/#/c/148635/_
In this case there were files that had a mixture of CRLF and LF.  The 
naive attempt to fix this using EGit (convert the whole file to LF 
endings) ended up with a Gerrit commit that in actual fact converted 
them all to CRLF rather than converting them all to LF as intended.  I 
needed to change the repository's autocrlf to false in order to 
correctly commit a fix with actual LF endings. Julian Honnen was super 
helpful and responsive processing this contributions. Thanks Julian!!
In any case, to fix these problems more easily, I've implemented a 
utility that I can use (or anyone can use) to automate the process.  
It uses JGit under the covers.  It copies the existing clone (to avoid 
re-cloning the entire repo and to avoid dirtying the existing clone), 
changes the copy's autocrlf to false, deletes the copy's working tree, 
and then does a reset hard to create a fresh new working tree that 
should (and generally does) contain text files with only LF in them.  
All the files in the working tree are then processed to convert any 
remaining CRLF to LF, i.e., to fix any files improperly commited to 
Git in the past.  From this copy one can easily commit to Gerrit a fix 
to correct all improper files.

I used that tool for the following Gerrit commit:
_https://git.eclipse.org/r/#/c/150035/_
I would like to fix all the platform's repositories, but I would not 
like to spend the next weeks waiting for reviews, re-basing multiple 
times, and hoping to eventually get the commit through.  I really do 
actually have better things to do with my time. :-P
I have commit rights for the Platform and Equinox (thanks Lars for 
starting an election for that) so I can do that on my own without 
bothering other people.  E.g., I could fix a feature's "null" provider:

_https://bugs.eclipse.org/bugs/show_bug.cgi?id=550648_
But I do not have commit rights for PDE and JDT.  The PDE folks are 
very responsive, so that's not a problem, but JDT seems to be a dead 
zone of silence.  Sorry for that. I don't intend to criticize anyone 
personally and of course I know that everyone else also has more 
important things to do with their time than deal with trivial deltas.  
Nevertheless, I need to understand how to get someone's attention to 
move forward in this process:

*What do I need to do so that some JDT committer looks a 150035?*
If trivial things can't move forward, it doesn't bode well for moving 
forward on more complex contributions to JDT...

Regards,
Ed___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/platform-dev



___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] CRLF Problems

2019-09-24 Thread Daniel Megert
Hi Ed

Where is the tool?

Dani



From:   Ed Merks 
To: "Eclipse platform general developers list." 

Date:   24.09.2019 08:45
Subject:[EXTERNAL] [platform-dev] CRLF Problems
Sent by:platform-dev-boun...@eclipse.org



Guys,
The platform's Git repositories are rife with text files that have been 
committed with CRLF rather than LF.  These things generally lead to 
totally confusing problems in EGit where files are shown as dirty with no 
apparent actual differences.  This is of course a barrier to entry for our 
contributors.  Worse still, the problems are really quite hard to fix.  
Previous attempts to fix such things indicate that it's all to easy to 
"fix" them incorrectly, e.g., 
https://git.eclipse.org/r/#/c/148635/
In this case there were files that had a mixture of CRLF and LF.  The 
naive attempt to fix this using EGit (convert the whole file to LF 
endings) ended up with a Gerrit commit that in actual fact converted them 
all to CRLF rather than converting them all to LF as intended.  I needed 
to change the repository's autocrlf to false in order to correctly commit 
a fix with actual LF endings.  Julian Honnen was super helpful and 
responsive processing this contributions.  Thanks Julian!!
In any case, to fix these problems more easily, I've implemented a utility 
that I can use (or anyone can use) to automate the process.  It uses JGit 
under the covers.  It copies the existing clone (to avoid re-cloning the 
entire repo and to avoid dirtying the existing clone), changes the copy's 
autocrlf to false, deletes the copy's working tree, and then does a reset 
hard to create a fresh new working tree that should (and generally does) 
contain text files with only LF in them.  All the files in the working 
tree are then processed to convert any remaining CRLF to LF, i.e., to fix 
any files improperly commited to Git in the past.  From this copy one can 
easily commit to Gerrit a fix to correct all improper files.
I used that tool for the following Gerrit commit:
  https://git.eclipse.org/r/#/c/150035/
I would like to fix all the platform's repositories, but I would not like 
to spend the next weeks waiting for reviews, re-basing multiple times, and 
hoping to eventually get the commit through.  I really do actually have 
better things to do with my time. :-P
I have commit rights for the Platform and Equinox (thanks Lars for 
starting an election for that) so I can do that on my own without 
bothering other people.  E.g., I could fix a feature's "null" provider:
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=550648
But I do not have commit rights for PDE and JDT.  The PDE folks are very 
responsive, so that's not a problem, but JDT seems to be a dead zone of 
silence.  Sorry for that.  I don't intend to criticize anyone personally 
and of course I know that everyone else also has more important things to 
do with their time than deal with trivial deltas.  Nevertheless, I need to 
understand how to get someone's attention to move forward in this process:
What do I need to do so that some JDT committer looks a 150035?
If trivial things can't move forward, it doesn't bode well for moving 
forward on more complex contributions to JDT...
Regards,
Ed___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev



___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] CRLF Problems

2019-09-24 Thread Andrey Loskutov
Ed,

 

You can ask here or you can add jdt-core-in...@eclipse.org to the bugzilla ticket where you want some feedback.

The reason for silence is that people are overcommitted to other, higher priority tasks.

 

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov

 
 

Gesendet: Dienstag, 24. September 2019 um 08:44 Uhr
Von: "Ed Merks" 
An: "Eclipse platform general developers list." 
Betreff: [platform-dev] CRLF Problems



Guys,

The platform's Git repositories are rife with text files that have been committed with CRLF rather than LF.  These things generally lead to totally confusing problems in EGit where files are shown as dirty with no apparent actual differences.  This is of course a barrier to entry for our contributors.  Worse still, the problems are really quite hard to fix.  Previous attempts to fix such things indicate that it's all to easy to "fix" them incorrectly, e.g.,

https://git.eclipse.org/r/#/c/148635/

In this case there were files that had a mixture of CRLF and LF.  The naive attempt to fix this using EGit (convert the whole file to LF endings) ended up with a Gerrit commit that in actual fact converted them all to CRLF rather than converting them all to LF as intended.  I needed to change the repository's autocrlf to false in order to correctly commit a fix with actual LF endings.  Julian Honnen was super helpful and responsive processing this contributions.  Thanks Julian!!

In any case, to fix these problems more easily, I've implemented a utility that I can use (or anyone can use) to automate the process.  It uses JGit under the covers.  It copies the existing clone (to avoid re-cloning the entire repo and to avoid dirtying the existing clone), changes the copy's autocrlf to false, deletes the copy's working tree, and then does a reset hard to create a fresh new working tree that should (and generally does) contain text files with only LF in them.  All the files in the working tree are then processed to convert any remaining CRLF to LF, i.e., to fix any files improperly commited to Git in the past.  From this copy one can easily commit to Gerrit a fix to correct all improper files.

I used that tool for the following Gerrit commit:

  https://git.eclipse.org/r/#/c/150035/

I would like to fix all the platform's repositories, but I would not like to spend the next weeks waiting for reviews, re-basing multiple times, and hoping to eventually get the commit through.  I really do actually have better things to do with my time. :-P

I have commit rights for the Platform and Equinox (thanks Lars for starting an election for that) so I can do that on my own without bothering other people.  E.g., I could fix a feature's "null" provider:

  https://bugs.eclipse.org/bugs/show_bug.cgi?id=550648

But I do not have commit rights for PDE and JDT.  The PDE folks are very responsive, so that's not a problem, but JDT seems to be a dead zone of silence.  Sorry for that.  I don't intend to criticize anyone personally and of course I know that everyone else also has more important things to do with their time than deal with trivial deltas.  Nevertheless, I need to understand how to get someone's attention to move forward in this process:

What do I need to do so that some JDT committer looks a 150035?

If trivial things can't move forward, it doesn't bode well for moving forward on more complex contributions to JDT...

Regards,
Ed
___ platform-dev mailing list platform-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev




___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] CRLF Problems

2019-09-24 Thread Ed Merks

Guys,

The platform's Git repositories are rife with text files that have been 
committed with CRLF rather than LF.  These things generally lead to 
totally confusing problems in EGit where files are shown as dirty with 
no apparent actual differences.  This is of course a barrier to entry 
for our contributors.  Worse still, the problems are really quite hard 
to fix.  Previous attempts to fix such things indicate that it's all to 
easy to "fix" them incorrectly, e.g.,


https://git.eclipse.org/r/#/c/148635/

In this case there were files that had a mixture of CRLF and LF. The 
naive attempt to fix this using EGit (convert the whole file to LF 
endings) ended up with a Gerrit commit that in actual fact converted 
them all to CRLF rather than converting them all to LF as intended.  I 
needed to change the repository's autocrlf to false in order to 
correctly commit a fix with actual LF endings. Julian Honnen was super 
helpful and responsive processing this contributions.  Thanks Julian!!


In any case, to fix these problems more easily, I've implemented a 
utility that I can use (or anyone can use) to automate the process.  It 
uses JGit under the covers.  It copies the existing clone (to avoid 
re-cloning the entire repo and to avoid dirtying the existing clone), 
changes the copy's autocrlf to false, deletes the copy's working tree, 
and then does a reset hard to create a fresh new working tree that 
should (and generally does) contain text files with only LF in them.  
All the files in the working tree are then processed to convert any 
remaining CRLF to LF, i.e., to fix any files improperly commited to Git 
in the past.  From this copy one can easily commit to Gerrit a fix to 
correct all improper files.


I used that tool for the following Gerrit commit:

  https://git.eclipse.org/r/#/c/150035/

I would like to fix all the platform's repositories, but I would not 
like to spend the next weeks waiting for reviews, re-basing multiple 
times, and hoping to eventually get the commit through. I really do 
actually have better things to do with my time. :-P


I have commit rights for the Platform and Equinox (thanks Lars for 
starting an election for that) so I can do that on my own without 
bothering other people.  E.g., I could fix a feature's "null" provider:


  https://bugs.eclipse.org/bugs/show_bug.cgi?id=550648

But I do not have commit rights for PDE and JDT.  The PDE folks are very 
responsive, so that's not a problem, but JDT seems to be a dead zone of 
silence.  Sorry for that.  I don't intend to criticize anyone personally 
and of course I know that everyone else also has more important things 
to do with their time than deal with trivial deltas.  Nevertheless, I 
need to understand how to get someone's attention to move forward in 
this process:


*What do I need to do so that some JDT committer looks a **150035?*

If trivial things can't move forward, it doesn't bode well for moving 
forward on more complex contributions to JDT...


Regards,
Ed

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev