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 <s...@stfx.eu> 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 <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? >> >> 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. > >
