> or a .iceberg file?
Why not use `.properties`?
{
#format : #tonel,
#eol: #lf
}
On Tue, Apr 10, 2018 at 11:55 PM, Esteban Lorenzano <esteba...@gmail.com>
wrote:
> or a .iceberg file?
>
> Esteban
>
> ps: yep, we need it… we will have it, why not start now?
>
> On 10 Apr 2018, at 23:52, Guillermo Polito <guillermopol...@gmail.com>
> wrote:
>
> It could be a checkbox in the "create repository dialog".
>
> "Use lf as default line ending"
>
> (and set it to true by default (?))
>
> On Tue, Apr 10, 2018 at 11:50 PM, Peter Uhnák <i.uh...@gmail.com> wrote:
>
>> An argument can be made that Pharo would _always_ produce LF.
>> I don't think I've ever needed _code_ to be CRLF in a ~decade of using
>> git on Windows. It was always just an annoyance.
>>
>> Peter
>>
>> On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano <esteba...@gmail.com>
>> wrote:
>>
>>> hi,
>>>
>>> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo <emaring...@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-cr
>>> lf-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
>
>
>
