April 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

by Guillermo Polito

I'd say yes? https://github.com/libgit2/libgit2/commit/b83fd07880307106deb0ac7cb0d415d85… ? On Tue, Apr 10, 2018 at 11:42 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Yes, that is the thing. Is libgit reading that properties file or not? > I'll do some digging.. > > On Tue, Apr 10, 2018 at 11:31 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> > Git for Windows even asks you if you want to automatically convert CRLF >> > to LF during checkin and back to CRLF on checkout. >> >> There are config options `core.eol` and `core.autocrlf`, but my >> impression was that Iceberg was somehow bypassing them? >> >> Peter >> >> >> On Tue, Apr 10, 2018 at 11:17 PM, Esteban A. Maringolo < >> emaringolo(a)gmail.com> wrote: >> >>> Not stricly related, or maybe yes, but years ago in InfOil we started >>> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used >>> that setting to store code in the repo, we didn't have any issues >>> >>> The .gitattributes contained this: >>> *.img binary >>> *.chg binary >>> *.sml binary >>> OurImage.img merge=ours >>> OurImage.chg merge=ours >>> *.pax eol=lf >>> *.cls eol=lf >>> >>> .pax was the "package definition" and "method extensions" (methods not >>> belonging to the package) file. >>> .cls was the 1 file per class+class-side used by this scheme >>> >>> Even we did everything in Windows for some reason I don't remember (+5 >>> yrs ago) LF was better for Gitlab. What I also don't remember is if >>> during the checkout in the Gitlab CI some conversion was used or not. I >>> don't remember a lot of things, but I can ask them if you want. >>> >>> But I can confirm that this "trick" does work. >>> >>> Git for Windows even asks you if you want to automatically convert CRLF >>> to LF during checkin and back to CRLF on checkout. >>> >>> Regards, >>> >>> >>> On 10/04/2018 18:05, Esteban Lorenzano wrote: >>> > Hi, >>> > >>> > Iâve been wondering how to better fix the problem of having windows and >>> > linux/macOS people contributing and the fact that files are written in >>> > their native system format (crlf windows, lf for the rest of the >>> world). >>> > >>> > I digged a bit and I found a couple a link that helped me (after trying >>> > to understand the >>> > doc): https://stackoverflow.com/questions/170961/whats-the-b >>> est-crlf-carriage-return-line-feed-handling-strategy-with-git >>> > >>> > and it seems adding a .gitattributes file with this content: >>> > >>> > # Auto detect text files and perform LF normalization >>> > *text=auto >>> > *.sttext merge=union eol=lf >>> > >>> > could fix the problem? >>> > can someone confirm this? >>> > >>> > (I confess this issue confuses me a lot :P) >>> > >>> > cheers! >>> > Esteban >>> >>> -- >>> Esteban A. Maringolo >>> >>> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 10, 2018

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

by Nicolai Hess

How about git config --system core.autocrlf input I use this in my opensmalltalk-vm git repository. (I think I saw this option in the appveyor windows-vm build) 2018-04-10 23:44 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > hi, > > > On 10 Apr 2018, at 23:17, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > > Not stricly related, or maybe yes, but years ago in InfOil we started > > using Dolphin Smalltalk PAX format[1] for packages with Git, and we used > > that setting to store code in the repo, we didn't have any issues > > > > The .gitattributes contained this: > > *.img binary > > *.chg binary > > *.sml binary > > OurImage.img merge=ours > > OurImage.chg merge=ours > > *.pax eol=lf > > *.cls eol=lf > > > > .pax was the "package definition" and "method extensions" (methods not > > belonging to the package) file. > > .cls was the 1 file per class+class-side used by this scheme > > > > Even we did everything in Windows for some reason I don't remember (+5 > > yrs ago) LF was better for Gitlab. What I also don't remember is if > > during the checkout in the Gitlab CI some conversion was used or not. I > > don't remember a lot of things, but I can ask them if you want. > > > > But I can confirm that this "trick" does work. > > > > Git for Windows even asks you if you want to automatically convert CRLF > > to LF during checkin and back to CRLF on checkout. > > exactly what I want, because pharo/iceberg/tonel uses the system line > ending to write the files :) > thanks! > > Esteban > > ps: otherwise I will need to add some support in-image and I donât think > is the best approach. > pps: now it remains to see if libgit2 honours the .gitattributes config > > > > > Regards, > > > > > > On 10/04/2018 18:05, Esteban Lorenzano wrote: > >> Hi, > >> > >> Iâve been wondering how to better fix the problem of having windows and > >> linux/macOS people contributing and the fact that files are written in > >> their native system format (crlf windows, lf for the rest of the world). > >> > >> I digged a bit and I found a couple a link that helped me (after trying > >> to understand the > >> doc): https://stackoverflow.com/questions/170961/whats-the- > best-crlf-carriage-return-line-feed-handling-strategy-with-git > >> > >> and it seems adding a .gitattributes file with this content: > >> > >> # Auto detect text files and perform LF normalization > >> *text=auto > >> *.sttext merge=union eol=lf > >> > >> could fix the problem? > >> can someone confirm this? > >> > >> (I confess this issue confuses me a lot :P) > >> > >> cheers! > >> Esteban > > > > -- > > Esteban A. Maringolo > > > > >

April 10, 2018

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

by Esteban Lorenzano

> On 10 Apr 2018, at 23:37, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Esteban, maybe (until the issue is properly resolved) Iceberg could have a conditional check that the repo is pharo itself and just forced the output to be LF? yes, it could. I will add that tomorrow *if* libgit does not follow .gitattributes. Esteban > > Peter > > On Tue, Apr 10, 2018 at 11:36 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > Hi, > > I --amend(ed) the commit after I converted it. If you've already pushed, you can force-push (there's no one using your code yet, so forcing shouldn't be an issue). > If you have multiple commits, then you'd need to filter all the commits (filter-branch iirc), so the newlines are correct in every single commit. > > Peter > > On Tue, Apr 10, 2018 at 11:31 PM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > Ah! > Ok. > > 2018-04-10 23:26 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>>: > Hi, > > did you commit on Windows? Because Iceberg seems to commit in platform-specific line endings, so I always need to convert it manually... ( https://github.com/PowerShell/Win32-OpenSSH/wiki/Dos2Unix---Text-file-forma… <https://github.com/PowerShell/Win32-OpenSSH/wiki/Dos2Unix---Text-file-forma…> ) > > And how can I do this, if my changes are managed by iceberg ? > Do I have to manually change the files in my local branch (right at my git directory) and can I then still upload the fix from within iceberg? > > > Notice also that all the files are from the same directory ... when you commit even a single change, the entire package is filed out. > > Peter > > > > > On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > Hi, > > I tried to create a pull request with IceBerg. > I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video. > > But I must have done something wrong. > This is my pull request: > https://github.com/pharo-project/pharo/pull/1189 <https://github.com/pharo-project/pharo/pull/1189> > But although I just changes one line in one method. > The gitub pull request side shows > Commit 1 Files changed 40! > But I did not change 40 files > > > And I still have problems viewing pull requests from within pharo: > > > > <grafik.png> > > > I thought this would work meanwhil. > > > Thanks in advance > > nicolai > > > > >

April 10, 2018

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

by Esteban Lorenzano

hi, > On 10 Apr 2018, at 23:17, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > Not stricly related, or maybe yes, but years ago in InfOil we started > using Dolphin Smalltalk PAX format[1] for packages with Git, and we used > that setting to store code in the repo, we didn't have any issues > > The .gitattributes contained this: > *.img binary > *.chg binary > *.sml binary > OurImage.img merge=ours > OurImage.chg merge=ours > *.pax eol=lf > *.cls eol=lf > > .pax was the "package definition" and "method extensions" (methods not > belonging to the package) file. > .cls was the 1 file per class+class-side used by this scheme > > Even we did everything in Windows for some reason I don't remember (+5 > yrs ago) LF was better for Gitlab. What I also don't remember is if > during the checkout in the Gitlab CI some conversion was used or not. I > don't remember a lot of things, but I can ask them if you want. > > But I can confirm that this "trick" does work. > > Git for Windows even asks you if you want to automatically convert CRLF > to LF during checkin and back to CRLF on checkout. exactly what I want, because pharo/iceberg/tonel uses the system line ending to write the files :) thanks! Esteban ps: otherwise I will need to add some support in-image and I donât think is the best approach. pps: now it remains to see if libgit2 honours the .gitattributes config > > Regards, > > > On 10/04/2018 18:05, Esteban Lorenzano wrote: >> Hi, >> >> Iâve been wondering how to better fix the problem of having windows and >> linux/macOS people contributing and the fact that files are written in >> their native system format (crlf windows, lf for the rest of the world). >> >> I digged a bit and I found a couple a link that helped me (after trying >> to understand the >> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-ret… >> >> and it seems adding a .gitattributes file with this content: >> >> # Auto detect text files and perform LF normalization >> *text=auto >> *.sttext merge=union eol=lf >> >> could fix the problem? >> can someone confirm this? >> >> (I confess this issue confuses me a lot :P) >> >> cheers! >> Esteban > > -- > Esteban A. Maringolo >

April 10, 2018

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

by Guillermo Polito

Yes, that is the thing. Is libgit reading that properties file or not? I'll do some digging.. On Tue, Apr 10, 2018 at 11:31 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Git for Windows even asks you if you want to automatically convert CRLF > > to LF during checkin and back to CRLF on checkout. > > There are config options `core.eol` and `core.autocrlf`, but my impression > was that Iceberg was somehow bypassing them? > > Peter > > > On Tue, Apr 10, 2018 at 11:17 PM, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > >> Not stricly related, or maybe yes, but years ago in InfOil we started >> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used >> that setting to store code in the repo, we didn't have any issues >> >> The .gitattributes contained this: >> *.img binary >> *.chg binary >> *.sml binary >> OurImage.img merge=ours >> OurImage.chg merge=ours >> *.pax eol=lf >> *.cls eol=lf >> >> .pax was the "package definition" and "method extensions" (methods not >> belonging to the package) file. >> .cls was the 1 file per class+class-side used by this scheme >> >> Even we did everything in Windows for some reason I don't remember (+5 >> yrs ago) LF was better for Gitlab. What I also don't remember is if >> during the checkout in the Gitlab CI some conversion was used or not. I >> don't remember a lot of things, but I can ask them if you want. >> >> But I can confirm that this "trick" does work. >> >> Git for Windows even asks you if you want to automatically convert CRLF >> to LF during checkin and back to CRLF on checkout. >> >> Regards, >> >> >> On 10/04/2018 18:05, Esteban Lorenzano wrote: >> > Hi, >> > >> > Iâve been wondering how to better fix the problem of having windows and >> > linux/macOS people contributing and the fact that files are written in >> > their native system format (crlf windows, lf for the rest of the >> world). >> > >> > I digged a bit and I found a couple a link that helped me (after trying >> > to understand the >> > doc): https://stackoverflow.com/questions/170961/whats-the- >> best-crlf-carriage-return-line-feed-handling-strategy-with-git >> > >> > and it seems adding a .gitattributes file with this content: >> > >> > # Auto detect text files and perform LF normalization >> > *text=auto >> > *.sttext merge=union eol=lf >> > >> > could fix the problem? >> > can someone confirm this? >> > >> > (I confess this issue confuses me a lot :P) >> > >> > cheers! >> > Esteban >> >> -- >> Esteban A. Maringolo >> >> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 10, 2018

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

by Peter UhnÃ¡k

Esteban, maybe (until the issue is properly resolved) Iceberg could have a conditional check that the repo is pharo itself and just forced the output to be LF? Peter On Tue, Apr 10, 2018 at 11:36 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > I --amend(ed) the commit after I converted it. If you've already pushed, > you can force-push (there's no one using your code yet, so forcing > shouldn't be an issue). > If you have multiple commits, then you'd need to filter all the commits > (filter-branch iirc), so the newlines are correct in every single commit. > > Peter > > On Tue, Apr 10, 2018 at 11:31 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> Ah! >> Ok. >> >> 2018-04-10 23:26 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> >>> Hi, >>> >>> did you commit on Windows? Because Iceberg seems to commit in >>> platform-specific line endings, so I always need to convert it manually... >>> ( https://github.com/PowerShell/Win32-OpenSSH/wiki/Dos2Unix- >>> --Text-file-format-converters ) >>> >> >> And how can I do this, if my changes are managed by iceberg ? >> Do I have to manually change the files in my local branch (right at my >> git directory) and can I then still upload the fix from within iceberg? >> >> >>> >>> Notice also that all the files are from the same directory ... when you >>> commit even a single change, the entire package is filed out. >>> >>> Peter >>> >>> >>> >>> >>> On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess <nicolaihess(a)gmail.com> >>> wrote: >>> >>>> Hi, >>>> >>>> I tried to create a pull request with IceBerg. >>>> I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video. >>>> >>>> But I must have done something wrong. >>>> This is my pull request: >>>> https://github.com/pharo-project/pharo/pull/1189 >>>> But although I just changes one line in one method. >>>> The gitub pull request side shows >>>> Commit 1 Files changed 40! >>>> But I did not change 40 files >>>> >>>> >>>> And I still have problems viewing pull requests from within pharo: >>>> >>>> >>>> >>>> >>>> >>>> >>>> I thought this would work meanwhil. >>>> >>>> >>>> Thanks in advance >>>> >>>> nicolai >>>> >>>> >>> >> >

April 10, 2018

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

by Peter UhnÃ¡k

Hi, I --amend(ed) the commit after I converted it. If you've already pushed, you can force-push (there's no one using your code yet, so forcing shouldn't be an issue). If you have multiple commits, then you'd need to filter all the commits (filter-branch iirc), so the newlines are correct in every single commit. Peter On Tue, Apr 10, 2018 at 11:31 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Ah! > Ok. > > 2018-04-10 23:26 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> Hi, >> >> did you commit on Windows? Because Iceberg seems to commit in >> platform-specific line endings, so I always need to convert it manually... >> ( https://github.com/PowerShell/Win32-OpenSSH/wiki/Dos2Unix- >> --Text-file-format-converters ) >> > > And how can I do this, if my changes are managed by iceberg ? > Do I have to manually change the files in my local branch (right at my git > directory) and can I then still upload the fix from within iceberg? > > >> >> Notice also that all the files are from the same directory ... when you >> commit even a single change, the entire package is filed out. >> >> Peter >> >> >> >> >> On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> Hi, >>> >>> I tried to create a pull request with IceBerg. >>> I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video. >>> >>> But I must have done something wrong. >>> This is my pull request: >>> https://github.com/pharo-project/pharo/pull/1189 >>> But although I just changes one line in one method. >>> The gitub pull request side shows >>> Commit 1 Files changed 40! >>> But I did not change 40 files >>> >>> >>> And I still have problems viewing pull requests from within pharo: >>> >>> >>> >>> >>> >>> >>> I thought this would work meanwhil. >>> >>> >>> Thanks in advance >>> >>> nicolai >>> >>> >> >

April 10, 2018

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

by Esteban Lorenzano

yes, thatâs why I asked about the problem with line endings. I will solve it, hehâ¦ donât worry. In the mean time I will fix the PR tomorrow. Esteban > On 10 Apr 2018, at 23:31, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Ah! > Ok. > > 2018-04-10 23:26 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>>: > Hi, > > did you commit on Windows? Because Iceberg seems to commit in platform-specific line endings, so I always need to convert it manually... ( https://github.com/PowerShell/Win32-OpenSSH/wiki/Dos2Unix---Text-file-forma… <https://github.com/PowerShell/Win32-OpenSSH/wiki/Dos2Unix---Text-file-forma…> ) > > And how can I do this, if my changes are managed by iceberg ? > Do I have to manually change the files in my local branch (right at my git directory) and can I then still upload the fix from within iceberg? > > > Notice also that all the files are from the same directory ... when you commit even a single change, the entire package is filed out. > > Peter > > > > > On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > Hi, > > I tried to create a pull request with IceBerg. > I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video. > > But I must have done something wrong. > This is my pull request: > https://github.com/pharo-project/pharo/pull/1189 <https://github.com/pharo-project/pharo/pull/1189> > But although I just changes one line in one method. > The gitub pull request side shows > Commit 1 Files changed 40! > But I did not change 40 files > > > And I still have problems viewing pull requests from within pharo: > > > > <grafik.png> > > > I thought this would work meanwhil. > > > Thanks in advance > > nicolai > > >

April 10, 2018

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

by Peter UhnÃ¡k

> Git for Windows even asks you if you want to automatically convert CRLF > to LF during checkin and back to CRLF on checkout. There are config options `core.eol` and `core.autocrlf`, but my impression was that Iceberg was somehow bypassing them? Peter On Tue, Apr 10, 2018 at 11:17 PM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > Not stricly related, or maybe yes, but years ago in InfOil we started > using Dolphin Smalltalk PAX format[1] for packages with Git, and we used > that setting to store code in the repo, we didn't have any issues > > The .gitattributes contained this: > *.img binary > *.chg binary > *.sml binary > OurImage.img merge=ours > OurImage.chg merge=ours > *.pax eol=lf > *.cls eol=lf > > .pax was the "package definition" and "method extensions" (methods not > belonging to the package) file. > .cls was the 1 file per class+class-side used by this scheme > > Even we did everything in Windows for some reason I don't remember (+5 > yrs ago) LF was better for Gitlab. What I also don't remember is if > during the checkout in the Gitlab CI some conversion was used or not. I > don't remember a lot of things, but I can ask them if you want. > > But I can confirm that this "trick" does work. > > Git for Windows even asks you if you want to automatically convert CRLF > to LF during checkin and back to CRLF on checkout. > > Regards, > > > On 10/04/2018 18:05, Esteban Lorenzano wrote: > > Hi, > > > > Iâve been wondering how to better fix the problem of having windows and > > linux/macOS people contributing and the fact that files are written in > > their native system format (crlf windows, lf for the rest of the world). > > > > I digged a bit and I found a couple a link that helped me (after trying > > to understand the > > doc): https://stackoverflow.com/questions/170961/whats- > the-best-crlf-carriage-return-line-feed-handling-strategy-with-git > > > > and it seems adding a .gitattributes file with this content: > > > > # Auto detect text files and perform LF normalization > > *text=auto > > *.sttext merge=union eol=lf > > > > could fix the problem? > > can someone confirm this? > > > > (I confess this issue confuses me a lot :P) > > > > cheers! > > Esteban > > -- > Esteban A. Maringolo > >

April 10, 2018

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

by Nicolai Hess

Ah! Ok. 2018-04-10 23:26 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > did you commit on Windows? Because Iceberg seems to commit in > platform-specific line endings, so I always need to convert it manually... > ( https://github.com/PowerShell/Win32-OpenSSH/wiki/ > Dos2Unix---Text-file-format-converters ) > And how can I do this, if my changes are managed by iceberg ? Do I have to manually change the files in my local branch (right at my git directory) and can I then still upload the fix from within iceberg? > > Notice also that all the files are from the same directory ... when you > commit even a single change, the entire package is filed out. > > Peter > > > > > On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> Hi, >> >> I tried to create a pull request with IceBerg. >> I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video. >> >> But I must have done something wrong. >> This is my pull request: >> https://github.com/pharo-project/pharo/pull/1189 >> But although I just changes one line in one method. >> The gitub pull request side shows >> Commit 1 Files changed 40! >> But I did not change 40 files >> >> >> And I still have problems viewing pull requests from within pharo: >> >> >> >> >> >> >> I thought this would work meanwhil. >> >> >> Thanks in advance >> >> nicolai >> >> >

April 10, 2018