[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [skalli-dev] EOL - Dissusion - Reformatting commit requested

Hi,

 

I think there are two things to consider here:

 

1.       For a short term approach, a reformatting patch is very good and pragmatic, it will solve our immediate problems

2.       Is this a long time approach? I am not so sure:

a.       We cannot really control what get’s submitted into the repository, we will get more committers, editors, accidents…

b.      We would HAVE to control what comes in, otherwise it will start to be mixed again

c.       I have the feeling there is no good centralized approach in a decentralized open source dev environment, we need something that works locally for the developer

d.      Shouldn’t it be possible for git to checkout files no matter how they are encoded in the repository and convert them to the encoding of the developer system on the fly? Then it wouldn’t matter how the files in the central repo are stored.

e.      Since this option might not yet be available, we should start some discussions about this on git, I can volunteer to drive it.

 

In the meantime I am of course fine with a quick fix patch, go for it J

 

 

Greetings, Robert

 

From: skalli-dev-bounces@xxxxxxxxxxx [mailto:skalli-dev-bounces@xxxxxxxxxxx] On Behalf Of Varwig, Britta
Sent: Mittwoch, 6. Juli 2011 15:57
To: Skalli project developer mailing list
Subject: Re: [skalli-dev] EOL - Dissusion - Reformatting commit requested

 

Hello Robert,

Ary you sure how slow “slow” might get?

I at least I expect that only the changed lines of a file will get the correct line endings, and all old lines still remain.

And you still will get into merge problems caused by different Line Endings.

 

But still there is the question,  how can we Mac and Unix satisfy when not converting all code?

 

So still vote for a separate patch.

 

Regards Britta

 

 

From: skalli-dev-bounces@xxxxxxxxxxx [mailto:skalli-dev-bounces@xxxxxxxxxxx] On Behalf Of Wetzold, Robert
Sent: Mittwoch, 6. Juli 2011 14:44
To: Skalli project developer mailing list
Subject: Re: [skalli-dev] EOL - Dissusion - Reformatting commit requested

 

Hi,

 

do we need a separate patch? As far as I understand autocrlf=true will check out files from the central repo converted to the format needed by the client anyway so there should be no merge conflicts resulting out of line endings except for local patches which are not yet committed? My understanding is that with autocrlf=true we will slowly convert the host repository to LF endings with each commit, don’t we?

 

 

Greetings, Robert

 

From: skalli-dev-bounces@xxxxxxxxxxx [mailto:skalli-dev-bounces@xxxxxxxxxxx] On Behalf Of Ochmann, Michael
Sent: Mittwoch, 6. Juli 2011 13:36
To: Skalli project developer mailing list
Subject: Re: [skalli-dev] EOL - Dissusion - Reformatting commit requested

 

+1 for the suggestion to use Unix-LF in our Eclipse git repo.

 

We had some discussions here with the EGit/Gerrit people, and they strongly encouraged us to use LF because it is better supported by all the git tools. Since all the Eclipse tools seem to be fine with core.autocrlf=true I see no objection against that proposal.

 

I would volunteer to commit that patch.

 

Cheers,

Michael

 

 

From: skalli-dev-bounces@xxxxxxxxxxx [mailto:skalli-dev-bounces@xxxxxxxxxxx] On Behalf Of Varwig, Britta
Sent: Mittwoch, 6. Juli 2011 10:49
To: Skalli project developer mailing list
Subject: Re: [skalli-dev] EOL - Dissusion - Reformatting commit requested

 

I have corrected the link to http://wiki.eclipse.org/Skalli/Contributor_Guide#EOL_properties

 

Some more details:

If you want to find out about the mode you can use the git bash command:  find ./org.* -type f | xargs dos2unix -t -v 2

 

I have played around with  different eclipse editors under windows and our current mixed code (New Line file line delimiter = Windows):

·         Target files:

o   LDI target: changes all EOL of a file to \r\n when deleting or inserting a new update-site

o   Text editor: leaves EOL as they are are

·         launch files:

o   Eclipse launch edior: converts all EOL to \r\n

·         java files

o   java editor:

o   does not change the EOF when eg. auto formatting the code (mixed mode stay mixed mode)

o   new insert lines via keybord-Return the in most cases \r\n EOL from the previous line

o   when copying lines it depends ...for source and destination EOL

·         pom.xml

o   pom editor: dont change the EOL

·         xml editor:

o   dont change the EOL when saving

o   new lines became the same as the surrounding once.

·         text editor:

o   dont changes the EOL by saving

o   new lines became the same as the surrounding once.

o   copying of lines depend on the surroundings/what’s copied

·         MANIFEST.MF

o   with manifest editor:

o   does not change the EOL when saving

 

The creation of new files with “New Line file line delimiter” = Unix does not work for all use cases.

Eg. a creation of a new Plugin-project dose not create all files with only a LF. Eg the Activator.java the .project and the .build had still windows LineEndings.

Creating a new class works correct. So you have to be very careful, when using the  option core.autocrlf=false.

 

Regards Britta

 

 

 

 

 

From: skalli-dev-bounces@xxxxxxxxxxx [mailto:skalli-dev-bounces@xxxxxxxxxxx] On Behalf Of Varwig, Britta
Sent: Dienstag, 5. Juli 2011 13:39
To: Skalli project developer mailing list
Subject: [skalli-dev] EOF - Dissusion - Reformatting commit requested

 

Hello,

 

I have found out that we in the Skalli source use the EOF in a strange mixed mode:

 

Some files contain CRLF (Windows mode) others only LF (Unix mode) and others both  mixed.

 

I have put some detailed explanations of using EOF into http://wiki.eclipse.org/Skalli/Contributor_Guide#EOF_properties.

 

As we can’t exclude MAC and UNIX user and therefore have to go for only having  LF in the GIT Repository.

 

So I suggest, if there are no doubts, that one of the committers do one big commit doing a Reformatting to LF.

 

Regards Britta