Smalltalk › Pharo › Pharo Smalltalk Developers

help wanted: normalising LF on tonel for Pharo project

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

25 messages Options

EstebanLM

help wanted: normalising LF on tonel for Pharo project

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

*.st text 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

Re: help wanted: normalising LF on tonel for Pharo project

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

Peter Uhnak

Re: help wanted: normalising LF on tonel for Pharo project

> 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 <[hidden email]> 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

Guillermo Polito

Re: help wanted: normalising LF on tonel for Pharo project

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 <[hidden email]> 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 <[hidden email]> 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

EstebanLM

Re: help wanted: normalising LF on tonel for Pharo project

In reply to this post by Esteban A. Maringolo

hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> 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
>

Nicolai Hess-3-2

Re: help wanted: normalising LF on tonel for Pharo project

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 <[hidden email]>:

hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> 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
>

Guillermo Polito

Re: help wanted: normalising LF on tonel for Pharo project

In reply to this post by Guillermo Polito

I'd say yes?

https://github.com/libgit2/libgit2/commit/b83fd07880307106deb0ac7cb0d415d85c27f465

On Tue, Apr 10, 2018 at 11:42 PM, Guillermo Polito <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

Web: 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Peter Uhnak

Re: help wanted: normalising LF on tonel for Pharo project

In reply to this post by EstebanLM

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 <[hidden email]> wrote:

hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> 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
>

EstebanLM

Re: help wanted: normalising LF on tonel for Pharo project

In reply to this post by Nicolai Hess-3-2

On 10 Apr 2018, at 23:47, Nicolai Hess <[hidden email]> wrote:

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)

that may work too.

but… I would like to also have a way to configure automatically that (in any case, please use it while the solution arrives).

Esteban

2018-04-10 23:44 GMT+02:00 Esteban Lorenzano <[hidden email]>:
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> 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
>

Guillermo Polito

Re: help wanted: normalising LF on tonel for Pharo project

In reply to this post by Peter Uhnak

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 <[hidden email]> 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 <[hidden email]> wrote:
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> 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
>

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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

EstebanLM

Re: help wanted: normalising LF on tonel for Pharo project

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> 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
>

--

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

Web: http://guillep.github.io
Phone: +33 06 52 70 66 13

Guillermo Polito

Re: help wanted: normalising LF on tonel for Pharo project

Both, the checkbox will be used to set the property in disk at some point :).

On Tue, Apr 10, 2018 at 11:55 PM, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> 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
>

--

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

Web: 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Peter Uhnak

Re: help wanted: normalising LF on tonel for Pharo project

In reply to this post by EstebanLM

> or a .iceberg file?

Why not use `.properties`?

{

#format : #tonel,

#eol: #lf

}

On Tue, Apr 10, 2018 at 11:55 PM, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> 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
>

--

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

Web: http://guillep.github.io
Phone: +33 06 52 70 66 13

Pharo Smalltalk Developers mailing list

Images, VMs and 32 vs 64bit

In reply to this post by EstebanLM

I was wondering if images for different platforms (Mac, Linux, Windows) and VMs (32bit, 64bit) are, code-wise, the same? By "the same", I mean do they all have the exact same code base or some classes/methods are in some and not in others or different?

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Peter Uhnak

Re: Images, VMs and 32 vs 64bit

> images for different platforms (Mac, Linux, Windows)

yes

It is the responsibility of the VM to contain the differences. Note that there's some "platform-specific" code, but the image contains the code for all platforms at once.

Generally speaking you can code on one platform, copy the image files to another and continue your work (although doing this can cause trouble, as e.g. some file paths may now point to non-existing locations).

You can download the images independently of the platform too (e.g. Pharo 6 images: http://files.pharo.org/image/60/ )

> VMs (32bit, 64bit)

yes?

the files are different, but I don't know if there's code difference, or if the images are just built with different memory layouts

Peter

On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:

---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>
Cc:
Bcc:
Date: Tue, 10 Apr 2018 22:13:18 +0000 (UTC)
Subject: Images, VMs and 32 vs 64bit
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs (32bit, 64bit) are, code-wise, the same? By "the same", I mean do they all have the exact same code base or some classes/methods are in some and not in others or different?

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Pharo Smalltalk Developers mailing list

Re: Images, VMs and 32 vs 64bit

Thanks!

I don't really care about the image format, my question was more oriented towards the code itself. As I don't have a Mac, I was curious as to whether there would be code differences between platforms, VMs and 32 vs 64bit distributions, code-wise!

On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák <[hidden email]> wrote:

> images for different platforms (Mac, Linux, Windows)

yes

It is the responsibility of the VM to contain the differences. Note that there's some "platform-specific" code, but the image contains the code for all platforms at once.

You can download the images independently of the platform too (e.g. Pharo 6 images: http://files.pharo.org/image/60/ )

> VMs (32bit, 64bit)

yes?

the files are different, but I don't know if there's code difference, or if the images are just built with different memory layouts

Peter

On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:

---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>
Cc:
Bcc:
Date: Tue, 10 Apr 2018 22:13:18 +0000 (UTC)
Subject: Images, VMs and 32 vs 64bit
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs (32bit, 64bit) are, code-wise, the same? By "the same", I mean do they all have the exact same code base or some classes/methods are in some and not in others or different?

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Guillermo Polito

Re: Images, VMs and 32 vs 64bit

VMs share most of the code. At least the basic interpreter, primitives and garbage collector.

But there are some platform specificities such as how some plugins are managed.

Also there are different JIT backends, one per platform.

I don't know if a VM comes shipped with all of them or just the one needed.

For more details, better ask the vm-dev mailing list.

On Wed, Apr 11, 2018 at 12:39 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:

---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>, "Peter Uhnák" <[hidden email]>
Cc:
Bcc:
Date: Tue, 10 Apr 2018 22:39:16 +0000 (UTC)
Subject: Re: [Pharo-dev] Images, VMs and 32 vs 64bit
Thanks!

I don't really care about the image format, my question was more oriented towards the code itself. As I don't have a Mac, I was curious as to whether there would be code differences between platforms, VMs and 32 vs 64bit distributions, code-wise!

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák <[hidden email]> wrote:

> images for different platforms (Mac, Linux, Windows)

yes
It is the responsibility of the VM to contain the differences. Note that there's some "platform-specific" code, but the image contains the code for all platforms at once.

Generally speaking you can code on one platform, copy the image files to another and continue your work (although doing this can cause trouble, as e.g. some file paths may now point to non-existing locations).
You can download the images independently of the platform too (e.g. Pharo 6 images: http://files.pharo.org/image/60/ )

> VMs (32bit, 64bit)

yes?
the files are different, but I don't know if there's code difference, or if the images are just built with different memory layouts

Peter

On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:

---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>
Cc:
Bcc:
Date: Tue, 10 Apr 2018 22:13:18 +0000 (UTC)
Subject: Images, VMs and 32 vs 64bit
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs (32bit, 64bit) are, code-wise, the same? By "the same", I mean do they all have the exact same code base or some classes/methods are in some and not in others or different?

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

philippeback

Re: Images, VMs and 32 vs 64bit

But once you are using an image on a given platform it may not work on another one just like that (e.g. FreeType will give trouble).

Phil

On Wed, Apr 11, 2018, 08:52 Guillermo Polito <[hidden email]> wrote:

VMs share most of the code. At least the basic interpreter, primitives and garbage collector.
But there are some platform specificities such as how some plugins are managed.
Also there are different JIT backends, one per platform.
I don't know if a VM comes shipped with all of them or just the one needed.

For more details, better ask the vm-dev mailing list.

On Wed, Apr 11, 2018 at 12:39 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:

---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>, "Peter Uhnák" <[hidden email]>
Cc:
Bcc:
Date: Tue, 10 Apr 2018 22:39:16 +0000 (UTC)
Subject: Re: [Pharo-dev] Images, VMs and 32 vs 64bit
Thanks!

I don't really care about the image format, my question was more oriented towards the code itself. As I don't have a Mac, I was curious as to whether there would be code differences between platforms, VMs and 32 vs 64bit distributions, code-wise!

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák <[hidden email]> wrote:

> images for different platforms (Mac, Linux, Windows)

yes
It is the responsibility of the VM to contain the differences. Note that there's some "platform-specific" code, but the image contains the code for all platforms at once.

Generally speaking you can code on one platform, copy the image files to another and continue your work (although doing this can cause trouble, as e.g. some file paths may now point to non-existing locations).
You can download the images independently of the platform too (e.g. Pharo 6 images: http://files.pharo.org/image/60/ )

> VMs (32bit, 64bit)

yes?
the files are different, but I don't know if there's code difference, or if the images are just built with different memory layouts

Peter

On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:

---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>
Cc:
Bcc:
Date: Tue, 10 Apr 2018 22:13:18 +0000 (UTC)
Subject: Images, VMs and 32 vs 64bit
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs (32bit, 64bit) are, code-wise, the same? By "the same", I mean do they all have the exact same code base or some classes/methods are in some and not in others or different?

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

--

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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Nicolas Cellier

Re: Images, VMs and 32 vs 64bit

In reply to this post by Guillermo Polito

The general principle is that the VM insulate almost every OS specific feature: the image sees the same virtual machine.

So you can save a 32bits image on an OS, and restart it on another.

The images effectively share the same code base whatever the OS.

There might be a plugin or two which are not present on all platforms though.

If FFI is used then a few more differences will generally creep in image side

That means that some OS dependent subclasses will care of implementation details at image side.
An image carries the implementation for all platforms, but only one is active at a time.
See senders of os osVersion osName platformName

For Squeak, the image code base is the same for 32 and 64bits and I presume it's also the case for Pharo.

But you cannot save on 32 bits and restart on 64bits et vice et versa.

There are again very few implementation details that are present at image side.

For example SmallInteger maxVal changes, there are also instances of SmallFloat64 on a 64bits image, but this should be mostly transparent.

See wordSize and senders for discovering a few parts of the image sensitive to the word size... (on Squeak, FFI/Alien, image segments, ...).

Concerning the underlying OS, , so it's again the same code base, you can save an image on an OS and restart it on another.

For the VM, as Guile said, there are more changes, because there you will find a lot more implementation details.

Since the VM is implemented in (mostly) in Smalltalk, if you load VMMaker then you will see abstract superclass, and 32/64 bits specializations for some part of the VM.

2018-04-11 8:51 GMT+02:00 Guillermo Polito <[hidden email]>:

VMs share most of the code. At least the basic interpreter, primitives and garbage collector.
But there are some platform specificities such as how some plugins are managed.
Also there are different JIT backends, one per platform.
I don't know if a VM comes shipped with all of them or just the one needed.

For more details, better ask the vm-dev mailing list.

On Wed, Apr 11, 2018 at 12:39 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:

---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>, "Peter Uhnák" <[hidden email]>
Cc:
Bcc:
Date: Tue, 10 Apr 2018 22:39:16 +0000 (UTC)
Subject: Re: [Pharo-dev] Images, VMs and 32 vs 64bit
Thanks!

I don't really care about the image format, my question was more oriented towards the code itself. As I don't have a Mac, I was curious as to whether there would be code differences between platforms, VMs and 32 vs 64bit distributions, code-wise!

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák <[hidden email]> wrote:

> images for different platforms (Mac, Linux, Windows)

yes
It is the responsibility of the VM to contain the differences. Note that there's some "platform-specific" code, but the image contains the code for all platforms at once.

Generally speaking you can code on one platform, copy the image files to another and continue your work (although doing this can cause trouble, as e.g. some file paths may now point to non-existing locations).
You can download the images independently of the platform too (e.g. Pharo 6 images: http://files.pharo.org/image/60/ )

> VMs (32bit, 64bit)

yes?
the files are different, but I don't know if there's code difference, or if the images are just built with different memory layouts

Peter

On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:

---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>
Cc:
Bcc:
Date: Tue, 10 Apr 2018 22:13:18 +0000 (UTC)
Subject: Images, VMs and 32 vs 64bit
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs (32bit, 64bit) are, code-wise, the same? By "the same", I mean do they all have the exact same code base or some classes/methods are in some and not in others or different?

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

--

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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Ben Coman

Re: help wanted: normalising LF on tonel for Pharo project

In reply to this post by EstebanLM

On 11 April 2018 at 05:05, Esteban Lorenzano <[hidden email]> 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

I see a few posts around that recommend reading http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

which about the above line says... "This is certainly better than requiring everyone to be on the same global setting for core.autocrlf, but it means that you really trust Git to do binary detection properly. In my opinion it is better to explicitly specify your text files that you want normalized."

and https://tinyurl.com/ya9xsprx says "We had a repo with * text=auto, and Git guessed wrong for an image file that it was a text file, causing it to corrupt it as it replaced CR + LF bytes with LF bytes in the object database."

I'm unsure. Without it the system is subject to different users' different global settings

and I'd guess that may be a more frequent problem than Git guessing wrong. The latter

can be fixed by a user adding an extra .gitattributes entry explicitly specifying the file was binary,

whereas the former seems to introduce a confounding factor.

So probably a good line to have.

*.st text merge=union eol=lf

could fix the problem?
can someone confirm this?

"eol=lf" looks appropriate...

https://www.scivision.co/git-line-endings-windows-cygwin-wsl/

Most editors on Windows transparently handle LF line endings.

https://en.wikipedia.org/wiki/Comparison_of_text_editors#Newline_support

" merge=union" I am not familiar with, but I read at... https://git-scm.com/docs/gitattributes

"union = Run 3-way file level merge for text files, but take lines from both versions, instead of leaving conflict markers.

This tends to leave the added lines in the resulting file in random** order and the user should verify the result.

Do not use this if you do not understand the implications."

What are the implications of lines being merged in a random order?

btw, has doing a callback from libgit to a custom merge driver in Pharo been considered?

https://libgit2.github.com/libgit2/#HEAD/group/callback/git_merge_driver_apply_fn

btw2, I found (https://githubengineering.com/move-fast/) interesting...

saying... "Despite being a C library, libgit2 contains many powerful abstractions to accomplish complex tasks that Git simply cannot do. One of these features are indexes that exist solely in memory and allow work-tree related operations to be performed without an actual working directory. [...] With the in-memory index, libgit2 is capable of merging two trees in a repository without having to check out any of their files on disk."

On 11 April 2018 at 05:55, Esteban Lorenzano <[hidden email]> wrote:

or a .iceberg file?

Esteban

ps: yep, we need it… we will have it, why not start now?

Do you mean Iceberg would clone a repo, and from its included .iceberg file

a matching .gitattributes file would be created?

That seems like double handling.

Why not have the user edit the .gitattributes file directly from Iceberg?

Iceberg might provide some appropriate templates.

cheers -ben