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