Tonel line end convention

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Tonel line end convention

Sven Van Caekenberghe-2
Hi,

I am wondering if the current approach regarding the Tonel line end convention is a good idea.

TonelWriter>>#newLine
  ^ OSPlatform current lineEnding

Although it is no problem to write Pharo code that transparently deals with (accepts) any line end convention, not specifying a fixed line end convention is bound to lead to version control problems, in my opinion.

Person 1 on platform A has line end convention #cr. After editing a single method, the .class.st is generated. Now the whole file is using #cr. From the standpoint of the version control system, *every* line is now potentially changed (when the previous line end convention was different).

Or am I missing something that mitigates this ?

Sven


Reply | Threaded
Open this post in threaded view
|

Re: Tonel line end convention

EstebanLM


> On 10 Nov 2017, at 07:25, Sven Van Caekenberghe <[hidden email]> wrote:
>
> Hi,
>
> I am wondering if the current approach regarding the Tonel line end convention is a good idea.
>
> TonelWriter>>#newLine
>  ^ OSPlatform current lineEnding
>
> Although it is no problem to write Pharo code that transparently deals with (accepts) any line end convention, not specifying a fixed line end convention is bound to lead to version control problems, in my opinion.
>
> Person 1 on platform A has line end convention #cr. After editing a single method, the .class.st is generated. Now the whole file is using #cr. From the standpoint of the version control system, *every* line is now potentially changed (when the previous line end convention was different).
>
> Or am I missing something that mitigates this ?

git can handle (ignore) line endings when diffing.
and also git can checkout with platform line endings, which means you can switch between mac/linux and windows *and* you can keep your files readable (which is the purpose of using platform line ending).

Esteban

>
> Sven
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Tonel line end convention

Sven Van Caekenberghe-2


> On 10 Nov 2017, at 12:26, Esteban Lorenzano <[hidden email]> wrote:
>
>
>
>> On 10 Nov 2017, at 07:25, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> Hi,
>>
>> I am wondering if the current approach regarding the Tonel line end convention is a good idea.
>>
>> TonelWriter>>#newLine
>> ^ OSPlatform current lineEnding
>>
>> Although it is no problem to write Pharo code that transparently deals with (accepts) any line end convention, not specifying a fixed line end convention is bound to lead to version control problems, in my opinion.
>>
>> Person 1 on platform A has line end convention #cr. After editing a single method, the .class.st is generated. Now the whole file is using #cr. From the standpoint of the version control system, *every* line is now potentially changed (when the previous line end convention was different).
>>
>> Or am I missing something that mitigates this ?
>
> git can handle (ignore) line endings when diffing.
> and also git can checkout with platform line endings, which means you can switch between mac/linux and windows *and* you can keep your files readable (which is the purpose of using platform line ending).

OK, that's settled then ;-)

> Esteban
>
>>
>> Sven


Reply | Threaded
Open this post in threaded view
|

Re: Tonel line end convention

gcotelli
In reply to this post by EstebanLM
Can we add an empty line at the end of every tonel file? GitHub diff tools work better that way and for the rest it shouldn't matter.  

On Fri, Nov 10, 2017 at 8:26 AM, Esteban Lorenzano <[hidden email]> wrote:


> On 10 Nov 2017, at 07:25, Sven Van Caekenberghe <[hidden email]> wrote:
>
> Hi,
>
> I am wondering if the current approach regarding the Tonel line end convention is a good idea.
>
> TonelWriter>>#newLine
>  ^ OSPlatform current lineEnding
>
> Although it is no problem to write Pharo code that transparently deals with (accepts) any line end convention, not specifying a fixed line end convention is bound to lead to version control problems, in my opinion.
>
> Person 1 on platform A has line end convention #cr. After editing a single method, the .class.st is generated. Now the whole file is using #cr. From the standpoint of the version control system, *every* line is now potentially changed (when the previous line end convention was different).
>
> Or am I missing something that mitigates this ?

git can handle (ignore) line endings when diffing.
and also git can checkout with platform line endings, which means you can switch between mac/linux and windows *and* you can keep your files readable (which is the purpose of using platform line ending).

Esteban

>
> Sven
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Tonel line end convention

Peter Uhnak
Does iceberg respect git line ending settings? https://help.github.com/articles/dealing-with-line-endings/

On Fri, Nov 10, 2017 at 2:02 PM, Gabriel Cotelli <[hidden email]> wrote:
Can we add an empty line at the end of every tonel file? GitHub diff tools work better that way and for the rest it shouldn't matter.  

On Fri, Nov 10, 2017 at 8:26 AM, Esteban Lorenzano <[hidden email]> wrote:


> On 10 Nov 2017, at 07:25, Sven Van Caekenberghe <[hidden email]> wrote:
>
> Hi,
>
> I am wondering if the current approach regarding the Tonel line end convention is a good idea.
>
> TonelWriter>>#newLine
>  ^ OSPlatform current lineEnding
>
> Although it is no problem to write Pharo code that transparently deals with (accepts) any line end convention, not specifying a fixed line end convention is bound to lead to version control problems, in my opinion.
>
> Person 1 on platform A has line end convention #cr. After editing a single method, the .class.st is generated. Now the whole file is using #cr. From the standpoint of the version control system, *every* line is now potentially changed (when the previous line end convention was different).
>
> Or am I missing something that mitigates this ?

git can handle (ignore) line endings when diffing.
and also git can checkout with platform line endings, which means you can switch between mac/linux and windows *and* you can keep your files readable (which is the purpose of using platform line ending).

Esteban

>
> Sven
>
>