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

[Thierry Goubier]

2018-04-12 7:51 GMT+02:00 Ben Coman :
>
>
> On 12 April 2018 at 12:39, Thierry Goubier 
> wrote:
>>
>> Le 12/04/2018 à 03:54, Ben Coman a écrit :
>>>
>>>
>>> I was thinking that a smalltalk-implemented merge algorithm would only be
>>> used for the Smalltal/Tonel code,
>>> not for any other files.  And maybe, when a merge is invoked from
>>> Iceberg, the callback to the merge-driver
>>> might present conflicts in a GUI to be resolved, but I guess such would
>>> require a threaded-VM.
>>
>>
>> Two things then.
>>
>> - What happens if the C developer does a merge in a multi-language project
>> containing tonel files?
>>
>> - What is the difference with setting and provides a merge driver in Git,
>> which has the ability to work even without libcgit?
>
>
> I don't quite understand the question.  By "setting" do you mean in
> .gitattributes?

Yes.

> The same merge-algorithm could be invoked in two ways.
>
> The first would be "externally" from the shell,
> booting an Image to invoke the merge-algorithm
> with the files-to-process as arguments. This wouldn't need libgit.
> Conflicts could left marked in text files similar to exiting merge,
> or the running Image could present them in a GUI to resolve.
> A tool is required either way.
> I guess one of the existing options does this already?

Yes. The GitFileTree-MergeDriver works like that. It is a headless
image, now buildt out of the Pharo6 minimal image, and it is called by
git for specific file types.

What is missing is the GUI part, like a git merge-tool like meld can do.

> But I had imagined a problem(?) in an already running Image, with Iceberg
> doing a merge through libgit
> being able to invoke the merge driver in the already running Image.
> Now you've made me think it through more, I see some holes.
> Perhaps its okay to have two Images running by using the "external" way
> anyway;

Yes: in that case the merge driver is called in another process
anyway. Also, you want to reduce the overhead (make the pharo-based
merge driver as  fast as possible to start, because git will start it
for each file to merge). The nice thing with that setup is that the
common ancestor search is done by git.

> or the merge done purely "internally" before touching git, and just present
> the resultant "index" to libgit;

That one has the issue of having to deal with non-smalltalk files
(i.e. write a generic merge tool). If you restrict yourself to
smalltalk merges, then that can be fine (i.e. you merge with
Monticello, and the resulting package is stored as a merge in the git
store). But you reverse who is the master... in the later, smalltalk
is the master, and git store smalltalk results; in the merge driver,
git is the master, and smalltalk does what git requires.

But someone can still come from the outside of the repo and do a merge
on the command line; which is also fine.

> and my idea is not needed as a third way.
> Now I find I don't know the depths of the Pharo / libgit interface enough to
> speculate further here.

Yes, it seems that there are multiple ways to interface with it.

Thierry

> cheers -ben

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

[Ben Coman]

On 12 April 2018 at 12:39, Thierry Goubier 
wrote:

> Le 12/04/2018 à 03:54, Ben Coman a écrit :
>
>>
>> I was thinking that a smalltalk-implemented merge algorithm would only be
>> used for the Smalltal/Tonel code,
>> not for any other files.  And maybe, when a merge is invoked from
>> Iceberg, the callback to the merge-driver
>> might present conflicts in a GUI to be resolved, but I guess such would
>> require a threaded-VM.
>>
>
> Two things then.
>
> - What happens if the C developer does a merge in a multi-language project
> containing tonel files?

- What is the difference with setting and provides a merge driver in Git,
> which has the ability to work even without libcgit?
>

I don't quite understand the question.  By "setting" do you mean in
.gitattributes?

The same merge-algorithm could be invoked in two ways.

The first would be "externally" from the shell,
booting an Image to invoke the merge-algorithm
with the files-to-process as arguments. This wouldn't need libgit.
Conflicts could left marked in text files similar to exiting merge,
or the running Image could present them in a GUI to resolve.
A tool is required either way.
I guess one of the existing options does this already?

But I had imagined a problem(?) in an already running Image, with Iceberg
doing a merge through libgit
being able to invoke the merge driver in the already running Image.
Now you've made me think it through more, I see some holes.
Perhaps its okay to have two Images running by using the "external" way
anyway;
or the merge done purely "internally" before touching git, and just present
the resultant "index" to libgit;
and my idea is not needed as a third way.
Now I find I don't know the depths of the Pharo / libgit interface enough
to speculate further here.

cheers -ben

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

[Thierry Goubier]

Le 12/04/2018 à 03:54, Ben Coman a écrit :





I was thinking that a smalltalk-implemented merge algorithm would only 
be used for the Smalltal/Tonel code,
not for any other files.  And maybe, when a merge is invoked from 
Iceberg, the callback to the merge-driver
might present conflicts in a GUI to be resolved, but I guess such would 
require a threaded-VM.


Two things then.

- What happens if the C developper does a merge in a multi-language 
project containing tonel files?


- What is the difference with setting and provides a merge driver in 
Git, which has the ability to work even without libcgit?


Thierry



cheers -ben




...

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

[Ben Coman]

On 12 April 2018 at 01:47, Thierry Goubier 
wrote:

> Hi Ben,
>
> Le 11/04/2018 à 16:37, Ben Coman a écrit :
>
>>
>>
>> On 11 April 2018 at 05: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
>> > 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.
>>
>> *.sttext 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 libgitto a custom merge driver in Pharo
>> been considered?
>> https://libgit2.github.com/libgit2/#HEAD/group/callback/git_
>> merge_driver_apply_fn
>>
>
> There is a merge driver for parts of the filetree format implemented with
> Pharo, it could be done on a more general basis if the Tonel format exhibit
> more conflicts than usual.
>
> But (and this is a big "but"), mixed Pharo / other things repositories
> with very large files to merge could make things very hard on a
> smalltalk-implemented merge algorithm.
>

I was thinking that a smalltalk-implemented merge algorithm would only be
used for the Smalltal/Tonel code,
not for any other files.  And maybe, when a merge is invoked from Iceberg,
the callback to the merge-driver
might present conflicts in a GUI to be resolved, but I guess such would
require a threaded-VM.

cheers -ben



> In most (all?) my professional work, this is the case. I have among my
> projects a mix FPGA design (verilog + vhdl) + C (drivers, runtime) +
> Smalltalk, and the smalltalk part is small.
>
> 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."
>>
>
> Yes, I considered that for GitFileTree. The current version uses
> fast-import and archive (resp. to write and read) and in truth could work
> on a bare repository, without working tree.
>
> Oh, by the way: it also solves the #lf issue, because you do everything
> the unix way, even on windows: GitFileTree now never touches a file of the
> host system.


>
> Thierry
>
>
>
>>
>> On 11 April 2018 at 05:55, Esteban Lorenzano> esteba...@gmail.com>>wr

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

[Thierry Goubier]

Hi Ben,

Le 11/04/2018 à 16:37, Ben Coman a écrit :



On 11 April 2018 at 05: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


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.

*.sttext 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 libgitto a custom merge driver in Pharo 
been considered?

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


There is a merge driver for parts of the filetree format implemented 
with Pharo, it could be done on a more general basis if the Tonel format 
exhibit more conflicts than usual.


But (and this is a big "but"), mixed Pharo / other things repositories 
with very large files to merge could make things very hard on a 
smalltalk-implemented merge algorithm.


In most (all?) my professionnal work, this is the case. I have among my 
projects a mix FPGA design (verilog + vhdl) + C (drivers, runtime) + 
Smalltalk, and the smalltalk part is small.



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."


Yes, I considered that for GitFileTree. The current version uses 
fast-import and archive (resp. to write and read) and in truth could 
work on a bare repository, without working tree.


Oh, by the way: it also solves the #lf issue, because you do everything 
the unix way, even on windows: GitFileTree now never touches a file of 
the host system.


Thierry




On 11 April 2018 at 05:55, Esteban Lorenzano>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

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

[Ben Coman]

On 11 April 2018 at 05: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
>

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

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

[Peter Uhnák]

>  or a .iceberg file?

Why not use `.properties`?

{
#format : #tonel,
#eol: #lf
}

On Tue, Apr 10, 2018 at 11:55 PM, Esteban Lorenzano 
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 
> 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  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 
>> wrote:
>>
>>> hi,
>>>
>>> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo 
>>> 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
> *
>
> *Web:* *http://guillep.github.io* 
> *Phone: *+33 06 52 70 66 13
>
>
>

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

[Guillermo Polito]

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 
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 
> 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  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 
>> wrote:
>>
>>> hi,
>>>
>>> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo 
>>> 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
> *
>
> *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

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

[Esteban Lorenzano]

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  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  > 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  > wrote:
> hi,
> 
> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo  > > 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

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

[Esteban Lorenzano]

> On 10 Apr 2018, at 23:47, Nicolai Hess  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  >:
> hi,
> 
> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo  > > 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
> >
> 
> 
> 

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

[Guillermo Polito]

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  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 
> wrote:
>
>> hi,
>>
>> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo 
>> 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

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

[Peter Uhnák]

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

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

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

[Guillermo Polito]

I'd say yes?

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

?

On Tue, Apr 10, 2018 at 11:42 PM, Guillermo Polito <
guillermopol...@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  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 <
>> 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.
>>>
>>> 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
> *
>
>
> *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

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

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

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

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

[Esteban Lorenzano]

hi,

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

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

[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  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 <
> 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.
>>
>> 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

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

[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  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
>
>

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

[Esteban A. Maringolo]

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

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

[Esteban Lorenzano]

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