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
On 10 Nov 2017, at 07:25, Sven Van Caekenberghe <sven@stfx.eu> 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
On 10 Nov 2017, at 12:26, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 10 Nov 2017, at 07:25, Sven Van Caekenberghe <sven@stfx.eu> 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
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 <estebanlm@gmail.com> wrote:
On 10 Nov 2017, at 07:25, Sven Van Caekenberghe <sven@stfx.eu> 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
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 <g.cotelli@gmail.com> 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 <estebanlm@gmail.com> wrote:
On 10 Nov 2017, at 07:25, Sven Van Caekenberghe <sven@stfx.eu> 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
participants (4)
-
Esteban Lorenzano -
Gabriel Cotelli -
Peter Uhnák -
Sven Van Caekenberghe