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.
[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
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?
On
25 February, 2016 at 05:22:51, Quentin Le Menez (quentin.lemenez@xxxxxxxxx)
wrote:
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.
2016-02-25
9:47 GMT+01:00 Quentin Le Menez <quentin.lemenez@xxxxxxxxx>:
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
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
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?
_______________________________________________
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
|