2018-05-23 15:28 GMT+02:00 Peter Uhnák <i.uh...@gmail.com>: > > > On Wed, May 23, 2018 at 6:42 AM, Ben Coman <b...@openinworld.com> wrote: >> >> >> >> On 22 May 2018 at 23:23, Tim Mackinnon <tim@testit.works> 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
