Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Thierry Goubier]

2018-05-23 15:28 GMT+02:00 Peter Uhnák :
>
>
> On Wed, May 23, 2018 at 6:42 AM, Ben Coman  wrote:
>>
>>
>>
>> On 22 May 2018 at 23:23, Tim Mackinnon  wrote:
>>>
>>> Hi - when trying out the new Iceberg with a bunch of developers and
>>> explaining the challenges of integrating git and files into a smalltalk
>>> realm of the image - there was a lot of interest in how this works.
>>>
>>> When you clone - you obviously see a series of files (in Tonel - nice)
>>> that are then brought into your image. If you edit a file like Readme.md
>>> (using a markdown editor) you will notice that git status will show you that
>>> this file has changed. However if you then edit some methods - and then look
>>> in the file system - git status doesn’t show these? This in retrospect
>>> possibly feels weird - or does it? I’m not sure anymore - and was wondering
>>> if there was a specific reason behind not mirroring code changes back to the
>>> file system as they happen?
>>
>>
>> I guess the conceptual model they have might be of Pharo as a text editor
>> directly changing the files.
>> Its interesting to consider how that would operate.  Changes are
>> immediately reflected in Epcia files,
>> and used to be immediately written to ".changes" file, so it seems
>> possible.
>
>
> This is indeed valuable when things go wrong.

At a point, I was considering using git as the changes file (every
method save and compile in Pharo -> a commit in git)

Didn't try to see if git would handle the load.

>> More interesting is what to do if the text file is edited outside Pharo.
>> If Pharo could observe this and then recompile the new file,
>> we might suddenly have a workable "external editor" workflow,
>> lack of which is a common complaint by some.
>
>
> I don't believe that it should be Pharo's concern to waste effort on
> supporting external editors -- it is throwing so much value of Pharo.
>
> That being said, until git conflicts can be resolved inside Pharo, it is
> necessary to be able to edit the files by hand. The ability to run the
> hand-resolved code without committing it (to verify it still works/compiles)
> seems like a worthwhile feature.

Good point.

>> However if you then edit some methods - and then look in the file system -
>> git status doesn’t show these? This in retrospect possibly feels weird - or
>> does it?
>
>
> With Iceberg you have two separate working copies. It is not weird from git
> perspective, however it is a rather unique setup -- even seasoned git users
> might say... "You can do that? :-o" :) (And yes, it adds some extra cost,
> but nothing is perfect.)

I considered eliminating one of the working copy when in Pharo, by
cloning repositories in RAW mode (without working tree). What you
wrote (the git fast-import layer) allows you to do that. But, to be
able to pull, you need to be able to be able to do a merge (and
resolve conflicts)... in Pharo memory.

Thierry

> Peter

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Peter Uhnák]

On Wed, May 23, 2018 at 6:42 AM, Ben Coman  wrote:

>
>
> On 22 May 2018 at 23:23, Tim Mackinnon  wrote:
>
>> Hi - when trying out the new Iceberg with a bunch of developers and
>> explaining the challenges of integrating git and files into a smalltalk
>> realm of the image - there was a lot of interest in how this works.
>>
>> When you clone - you obviously see a series of files (in Tonel - nice)
>> that are then brought into your image. If you edit a file like Readme.md
>> (using a markdown editor) you will notice that git status will show you
>> that this file has changed. However if you then edit some methods - and
>> then look in the file system - git status doesn’t show these? This in
>> retrospect possibly feels weird - or does it? I’m not sure anymore - and
>> was wondering if there was a specific reason behind not mirroring code
>> changes back to the file system as they happen?
>>
>
> I guess the conceptual model they have might be of Pharo as a text editor
> directly changing the files.
> Its interesting to consider how that would operate.  Changes are
> immediately reflected in Epcia files,
> and used to be immediately written to ".changes" file, so it seems
> possible.
>

This is indeed valuable when things go wrong.



> More interesting is what to do if the text file is edited outside Pharo.
> If Pharo could observe this and then recompile the new file,
> we might suddenly have a workable "external editor" workflow,
> lack of which is a common complaint by some.
>

I don't believe that it should be Pharo's concern to waste effort on
supporting external editors -- it is throwing so much value of Pharo.

That being said, until git conflicts can be resolved inside Pharo, it is
necessary to be able to edit the files by hand. The ability to run the
hand-resolved code without committing it (to verify it still
works/compiles) seems like a worthwhile feature.

However if you then edit some methods - and then look in the file system -
> git status doesn’t show these? This in retrospect possibly feels weird - or
> does it?
>

With Iceberg you have two separate working copies. It is not weird from git
perspective, however it is a rather unique setup -- even seasoned git users
might say... "You can do that? :-o" :) (And yes, it adds some extra cost,
but nothing is perfect.)

Peter

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Ben Coman]

On 22 May 2018 at 23:23, Tim Mackinnon  wrote:

> Hi - when trying out the new Iceberg with a bunch of developers and
> explaining the challenges of integrating git and files into a smalltalk
> realm of the image - there was a lot of interest in how this works.
>
> When you clone - you obviously see a series of files (in Tonel - nice)
> that are then brought into your image. If you edit a file like Readme.md
> (using a markdown editor) you will notice that git status will show you
> that this file has changed. However if you then edit some methods - and
> then look in the file system - git status doesn’t show these? This in
> retrospect possibly feels weird - or does it? I’m not sure anymore - and
> was wondering if there was a specific reason behind not mirroring code
> changes back to the file system as they happen?
>

I guess the conceptual model they have might be of Pharo as a text editor
directly changing the files.
Its interesting to consider how that would operate.  Changes are
immediately reflected in Epcia files,
and used to be immediately written to ".changes" file, so it seems possible.

More interesting is what to do if the text file is edited outside Pharo.
If Pharo could observe this and then recompile the new file,
we might suddenly have a workable "external editor" workflow,
lack of which is a common complaint by some.

cheers -ben


>
> When you branch in Pharo, a command line git status does show that change
> - so some things clearly are being mirrored, just not code (Which I’m guess
> happens briefly when you click commit?).
>
> I’m curious now to understand the tradeoffs.
>
> Tim
>
> p.s. it is very nice for small private projects, to use a git client on
> your phone - edit a method or two on the train, commit your changes and
> then see your CI build the results and deploy a new website by the time you
> get off… yes its not the rich smalltalk environment for bigger changes -
> but tiny stuff, its quite nice to fallback on the traditional way.
>
>
>

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Sean P. DeNigris]

Esteban A. Maringolo wrote
> there is no way to "save" the package other than committing its changes to
> the repo.

In the past, I sorely missed a feature like this. When Iceberg (or I!) was
confused about the state of the local repo/changes/whatever, I wished I had
a way to write to disk and then verify that it did "the right thing" and
manually fix with "normal" git tools if needed. Maybe Iceberg has improved
enough to make this unneeded…



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Tim Mackinnon]

Actually I missed that one - thanks. Would have been a useful one to show 
everyone when we went through the commit process - it’s very good.

Sent from my iPhone



Sent from my iPhone
> On 22 May 2018, at 17:16, Sven Van Caekenberghe  wrote:
> 
> Partial answer, but you saw this, right ?
> 
> https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary
> 
>> On 22 May 2018, at 17:23, Tim Mackinnon  wrote:
>> 
>> Hi - when trying out the new Iceberg with a bunch of developers and 
>> explaining the challenges of integrating git and files into a smalltalk 
>> realm of the image - there was a lot of interest in how this works.
>> 
>> When you clone - you obviously see a series of files (in Tonel - nice) that 
>> are then brought into your image. If you edit a file like Readme.md (using a 
>> markdown editor) you will notice that git status will show you that this 
>> file has changed. However if you then edit some methods - and then look in 
>> the file system - git status doesn’t show these? This in retrospect possibly 
>> feels weird - or does it? I’m not sure anymore - and was wondering if there 
>> was a specific reason behind not mirroring code changes back to the file 
>> system as they happen?
>> 
>> When you branch in Pharo, a command line git status does show that change - 
>> so some things clearly are being mirrored, just not code (Which I’m guess 
>> happens briefly when you click commit?).
>> 
>> I’m curious now to understand the tradeoffs.
>> 
>> Tim
>> 
>> p.s. it is very nice for small private projects, to use a git client on your 
>> phone - edit a method or two on the train, commit your changes and then see 
>> your CI build the results and deploy a new website by the time you get off… 
>> yes its not the rich smalltalk environment for bigger changes - but tiny 
>> stuff, its quite nice to fallback on the traditional way.
> 
> 

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Esteban A. Maringolo]

I agree with you that it is weird, but as I understand it it is
because the process of "Saving" a package and "Committing" it is
merged into a single action, so there is no way to "save" the package
other than committing its changes to the repo.

This has the drawback you mentioned, but I guess this enables you to
simultaneously save the same package to more than one repository.

Maybe a diagram could make the whole picture more clear.

Regards,

Esteban A. Maringolo


2018-05-22 12:23 GMT-03:00 Tim Mackinnon :
> Hi - when trying out the new Iceberg with a bunch of developers and 
> explaining the challenges of integrating git and files into a smalltalk realm 
> of the image - there was a lot of interest in how this works.
>
> When you clone - you obviously see a series of files (in Tonel - nice) that 
> are then brought into your image. If you edit a file like Readme.md (using a 
> markdown editor) you will notice that git status will show you that this file 
> has changed. However if you then edit some methods - and then look in the 
> file system - git status doesn’t show these? This in retrospect possibly 
> feels weird - or does it? I’m not sure anymore - and was wondering if there 
> was a specific reason behind not mirroring code changes back to the file 
> system as they happen?
>
> When you branch in Pharo, a command line git status does show that change - 
> so some things clearly are being mirrored, just not code (Which I’m guess 
> happens briefly when you click commit?).
>
> I’m curious now to understand the tradeoffs.
>
> Tim
>
> p.s. it is very nice for small private projects, to use a git client on your 
> phone - edit a method or two on the train, commit your changes and then see 
> your CI build the results and deploy a new website by the time you get off… 
> yes its not the rich smalltalk environment for bigger changes - but tiny 
> stuff, its quite nice to fallback on the traditional way.
>
>

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Sven Van Caekenberghe]

Partial answer, but you saw this, right ?

https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary

> On 22 May 2018, at 17:23, Tim Mackinnon  wrote:
> 
> Hi - when trying out the new Iceberg with a bunch of developers and 
> explaining the challenges of integrating git and files into a smalltalk realm 
> of the image - there was a lot of interest in how this works.
> 
> When you clone - you obviously see a series of files (in Tonel - nice) that 
> are then brought into your image. If you edit a file like Readme.md (using a 
> markdown editor) you will notice that git status will show you that this file 
> has changed. However if you then edit some methods - and then look in the 
> file system - git status doesn’t show these? This in retrospect possibly 
> feels weird - or does it? I’m not sure anymore - and was wondering if there 
> was a specific reason behind not mirroring code changes back to the file 
> system as they happen?
> 
> When you branch in Pharo, a command line git status does show that change - 
> so some things clearly are being mirrored, just not code (Which I’m guess 
> happens briefly when you click commit?).
> 
> I’m curious now to understand the tradeoffs.
> 
> Tim
> 
> p.s. it is very nice for small private projects, to use a git client on your 
> phone - edit a method or two on the train, commit your changes and then see 
> your CI build the results and deploy a new website by the time you get off… 
> yes its not the rich smalltalk environment for bigger changes - but tiny 
> stuff, its quite nice to fallback on the traditional way.
> 
> 

[Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Tim Mackinnon]

Hi - when trying out the new Iceberg with a bunch of developers and explaining 
the challenges of integrating git and files into a smalltalk realm of the image 
- there was a lot of interest in how this works.

When you clone - you obviously see a series of files (in Tonel - nice) that are 
then brought into your image. If you edit a file like Readme.md (using a 
markdown editor) you will notice that git status will show you that this file 
has changed. However if you then edit some methods - and then look in the file 
system - git status doesn’t show these? This in retrospect possibly feels weird 
- or does it? I’m not sure anymore - and was wondering if there was a specific 
reason behind not mirroring code changes back to the file system as they happen?

When you branch in Pharo, a command line git status does show that change - so 
some things clearly are being mirrored, just not code (Which I’m guess happens 
briefly when you click commit?).

I’m curious now to understand the tradeoffs.

Tim

p.s. it is very nice for small private projects, to use a git client on your 
phone - edit a method or two on the train, commit your changes and then see 
your CI build the results and deploy a new website by the time you get off… yes 
its not the rich smalltalk environment for bigger changes - but tiny stuff, its 
quite nice to fallback on the traditional way.