Tod/Norbert - I won���t shy away from answering your comments on this - but if its ok - lets move that conversation to a new thread. I don���t want to distract away from how one actually does some form of atomic checkin (and I���m talking a small one - one Smalltalk class, one associated text file).

I earlier tried doing a change on a class - committing, but not pushing and then switching to IntelliJ to then commit and push my config file change - and it didn���t seem to work - which surprised me, so I���m gong to redo my test again with the the latest Iceberg 1.1 in a new image (and also make sure my IntelliJ is attached to the same local repo). This seems like the closest root to how I would like to work (albeit a slightly bit more complicated than I would like, but certainly doable).

Tim

On 15 Jun 2018, at 18:26, Todd Blanchard <tblanchard@mac.com> wrote:



On Jun 15, 2018, at 2:05 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:



On 15 Jun 2018, at 10:29, Tim Mackinnon <tim@testit.works> wrote:


In many parts of the dev world - every commit should be shippable, meaning atomic - particularly with the use of CI systems (Travis, Gitlab etc) that build on every commit. 

but then, you mean every *push* should be shippable :)
that���s something I agree :)

The way we run projects - pushing to master is forbidden.  You push your work to a feature specific branch, a CI server runs all the tests in the branch every push.  We create pull requests from the github project page, people review them and when the tests are green and reviewers approve, we perform the merge on github.

Never touch master (or whatever branch you pick for main trunk) outside of github.  Always perform new work in new branch.