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 <tim@testit.works>: > 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. > >
