| Re: [mdt-papyrus.dev] The .gitattributes file and line-ending conversion |
Thanks, Tom,That was helpful. Clearly, I was misunderstanding the meaning of “auto”. Being a long-time Mac user, I have been accustomed to autocrlf=input and was thinking that auto was the reason why I was getting CRLF endings when, in fact, the opposite was true: I am now getting LF endings in the index for files that autocrlf=input was leaving as CRLF in the index. What I wasn’t understanding before was that the entire discussion isn’t about the line endings in the checkout workspace, but rather it’s about the line endings in the index, which accurately reflects what will end up in the shared repository.
So, if my new understanding is correct, I am more comfortable. I now am sitting on a commit that converts the line endings of nearly 16000 files (see transcript, below). Oddly, though, I still see that Benoit’s script finds a few hundred text files that have CRLF endings, for what reason I don't know. I won’t be entirely comfortable until I know what’s going on with those.Another question that concerns me: we know that JGit doesn’t support the .gitattributes file, at least not the line-ending settings in it. So, if I were to push these thousands of changes, what would the impact be afterwards of developers using EGit to commit changes:
- on Windows with config.autocrlf=false? Wouldn’t that introduce CRLFs back into the repo?
- on Linux/Mac with config.autocrlf=??? ? Can these people do any further damage to the repo once it has been LFized? I suspect not
Which is all to say that I think the long-term viability of the plan still depends on Windows users all continuing to have core.autocrlf=true in their global configs, which is probably the case and isn’t a new requirement/constraint anyways.Cheers,Christian———— 8< ————✓ 🍔 0 591 ~/git/Papyrus (master) $ git commit -m "Normalize all the line endings"warning: CRLF will be replaced by LF in extraplugins/facade/org.eclipse.papyrus.facade.editor/plugin.properties.The file will have its original line endings in your working directory.warning: CRLF will be replaced by LF in extraplugins/layers/org.eclipse.papyrus.layers.stackmodel.editor/plugin.properties.The file will have its original line endings in your working directory.warning: CRLF will be replaced by LF in extraplugins/soaml/org.eclipse.papyrus.soaml.profile.validation/plugin.xml.The file will have its original line endings in your working directory.warning: CRLF will be replaced by LF in plugins/customization/org.eclipse.papyrus.infra.gmfdiag.expansion.editor/plugin.properties.The file will have its original line endings in your working directory.warning: CRLF will be replaced by LF in plugins/infra/core/org.eclipse.papyrus.infra.core.sasheditor/plugin.properties....The file will have its original line endings in your working directory.warning: CRLF will be replaced by LF in plugins/uml/diagram/org.eclipse.papyrus.uml.diagram.timing/plugin.properties.The file will have its original line endings in your working directory.warning: CRLF will be replaced by LF in plugins/uml/diagram/org.eclipse.papyrus.uml.diagram.usecase/plugin.properties.The file will have its original line endings in your working directory.warning: CRLF will be replaced by LF in tests/debug/plugins/core/org.eclipse.papyrus.extendedtypes.editor/plugin.properties.The file will have its original line endings in your working directory.warning: CRLF will be replaced by LF in tests/junit/plugins/uml/diagram/org.eclipse.papyrus.uml.diagram.component.tests/plugin.properties.The file will have its original line endings in your working directory.15796 files changed, 3434099 insertions(+), 3434099 deletions(-)✓ 🍔 0 592 ~/git/Papyrus (master) $ checkcrlfCRLF: 281All EOLs must be LF and not CRLF. See target/crlf.log for details.On 25 February, 2016 at 13:44:13, Tom Morris (tfmorris@xxxxxxxxx) wrote:
In my experience, "text=auto" will convert text files to LF-only in the repo and convert to a platform-specific format on checkout.Github has a good page on how to normalize line endings in a repo:Tom_______________________________________________
On Thu, Feb 25, 2016 at 12:16 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Benoit,Are you sure that the .gitattributes does what you think it does? By my reading, it enforces CRLF line endings on all platforms. The ‘text=auto’ directive is like ‘core.autocrlf=true’ in the .gitconfig, which makes the local git workspace have \r\n endings in all text files. [1]The CRLF-grepping script in your SysML build (thanks for that!) finds 16066 violations in my git checkout. Which is to say, 16066 files that have a \r\n line ending.If we want to standardize on simple \n endings in the workspace on all platforms, I don’t think git actually provides a way to do that. The best it will do is to leave the line endings as they were in the repository, which will be a mix of some files having \r\n and some having \n alone.cW[1] https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#Formatting-and-Whitespace
On 25 February, 2016 at 11:39:38, MAGGI Benoit (benoit.maggi@xxxxxx) wrote:
_______________________________________________Hi Christian,
The .gitattributes is configured to enforce linux EOL, so you should have less problem than a windows user.
Can you also try to add your problematic extensions to .gitattributes (as binary for odt,ppt) ?
An option is to duplicate the Papyrus-gerrit job and add the script that check EOL [1] to check if the lines are correct.
Regards,
Benoit
1 : https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/.gitattributes
2 : https://hudson.eclipse.org/papyrus/view/Sysml/job/papyrus-sysml-gerrit/configure
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : jeudi 25 février 2016 16:50
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : Re: [mdt-papyrus.dev] The .gitattributes file and line-ending conversion
Hi, Benoit, Quentin,
Thanks for your responses. Not the first time I suppose wrongly, by a long shot! Perhaps you are not seeing line conversions in git because you are on a platform (Windows) whose native line-ending convention matches what is now configured in the .gitattributes?
I’m not certain that I’m having this problem because I have modified so many files in my local repository. Yes, I’ve touched thousands in the last couple of months, but amongst these 15800 files are a great many that I have never had occasion to touch for any reason (for example, in the developer documents tree, various OpenOffice files).
You can understand that I am nervous about pushing a change like this, but I don't know even whether it would actually modify the central git repo or only my clone’s view of it (what line endings do these files actually have at git.eclipse.org?). Any other votes for or against proceeding with this conversion?
Christian
On 25 February, 2016 at 05:22:51, Quentin Le Menez (quentin.lemenez@xxxxxxxxx) wrote:
Hi again,
It seems that my problem resided in the fact that I forgot to set the Unix formatting in my new eclipse installation... setting the correct parameters (as well as setting the core.autocrlf to false) seem to bring me back to the correct git behavior.
I will verify that it will not break again in the next few days and update the wiki (if it was not already mentioned) with the necessary information on how to do it.
Quentin
2016-02-25 9:47 GMT+01:00 Quentin Le Menez <quentin.lemenez@xxxxxxxxx>:
Hi,
Same here I use the command lines (via cygwin as well), but I admit I recently had some problems with those pesky line endings (the --checkout, reset, and stash that basically did nothing or close to it) ...
If you have the authorization however I would like it of you can push the "correct" line endings so as to avoid me some annoying, albeit not that time consuming, commands (such as editing the config core) to return the repo to its former clean glory ^^Thanks,
Quentin
2016-02-25 9:05 GMT+01:00 MAGGI Benoit <Benoit.MAGGI@xxxxxx>:
Hi Christian,
You suppose wrongJ,
I use command-line (on Cygwin) for a lot of git manipulations and other committers are also using the command line daily.
Basically only commit and push are working fast enough in Egit for the Papyrus core repository, so I use command line for other operations.
I didn’t get any problems but I usually try to work on small patchset
I suppose that since you are the one making the biggest refactoring, you are the one that is really impacted.
In short: I would prefer to keep this .gitattribute and change all the files
(since at the end the goal is to stop having EOL problems)
ð No problem for me if you want to push a big conversion commit.
ð You can add this script [1] in Papyrus gerrit if you want to check all line ending
Regards,
Benoit
1 : https://hudson.eclipse.org/papyrus/view/Sysml/job/papyrus-sysml-gerrit/configure
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : jeudi 25 février 2016 04:33
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : [mdt-papyrus.dev] The .gitattributes file and line-ending conversion
Hi, again,
(busy night here in Ottawa, it would seem)
Some weeks ago, the Papyrus git repo acquired a .gitattributes file that sets automatic CRLF conversion for all text files in the repository. In theory, this is a good thing. But, so far, EGit/JGit does not recognize this file and its CRLF configuration. I suppose that most Papyrus developers (all but me?) use EGit exclusively for version control operations, or else are on a platform where the whitespace conversion has no impact.
On my Mac system, I have 15800 files that git (the command-line tool) requires me to commit to convert line endings. Because I am not certain that I should do this conversion, I cannot use the command-line or GUI tools such as Tower or GitUp to perform rebases and other complex operations, but must use EGit which on such operations scales very badly for workspaces like Papyrus that comprise several hundred projects.
Does anybody know of a good reason why I should not commit these 15800 line-ending conversion and push them to the central git repository so that everybody may now see text file line endings and I may actually use the git command-line again? Or should we remove the .gitattributes file, since it has no effect on EGit anyways?
Thanks,
Christian
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev