| Re: [skalli-dev] EOL - Dissusion - Reformatting commit requested |
Hi, since the discussion seems to have settled in favor for converting all line endings to *nix-LF I’ll prepare the necessary patch with Brittas help. If you have any large/critical patch that may be affected by this (collisions are likely to happen once that formatting patch is committed) please raise your hand ASAP. Regards Michael From: skalli-dev-bounces@xxxxxxxxxxx [mailto:skalli-dev-bounces@xxxxxxxxxxx] On Behalf Of Wetzold, Robert Hi, setting autocrlf to true would be a possible solution. We talked about this option already with our git experts and there are pro & cons. Drawbacks are that files will be auto-converted and as it seems the detection of binary vs text files is not 100% bullet proof. Also, there are people who feel uncomfortable knowing their SCM does some magic without them being in control. I think we should have the formatting patch as a good start. I just quickly developed a tiny checkstyle rule which we can attach to our Hudson to autocheck our files which should also solve the long term problem since we can use it in the Hudson Voter as soon as it is available at Eclipse. Regards, Robert From: skalli-dev-bounces@xxxxxxxxxxx [mailto:skalli-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Kaufmann Isn't that (2d) what core.autocrlf=true does? see e.g. http://help.github.com/line-endigs/ Simon 2011/7/8 Wetzold, Robert <robert.wetzold@xxxxxxx> 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
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 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 +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 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 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
|