My two cents: having different images for branches is a good workaround, but I will have to manually control those images, while git abstracts this a little since I have a way to tell it to stash and bring back work in progress. Depending on the project, I think loading a new image with a fresh HEAD would require a lot of time to bring all dependencies and compile, while just getting changes made at certain point from an image and stash them would be much faster, am I wrong?
On Tue, Sep 13, 2016 at 6:20 AM, Nicolas Passerini <npasser...@gmail.com> wrote: > Hi Holger, I think that both patterns are currently supported (in beta > version), but maybe we do not use exactly the same tools. > > First, Iceberg does not use the concept of "stash". The git stash changes > the file in your git working copy (on your file system), while your > (modified) code is not there, is in the Pharo image. > > Going deeper into it, we understand git is very powerful but we do not > believe that git is the ultimate perfect code versioning tool. We think > that there are some git usage patterns that tend to be difficult to > understand so we are trying to create a better abstraction on top of that. > Also we would like to come up with an abstraction that works not only for > git but for other repositories. > > So, we try to support the kind of requirements you are worried about, but > maybe not in the same way that the command line tools you are used to. I > also have been working with git in languages like Scala, Javascript, Xtend, > etc and I was used to the command line tools... so now the task for me is > to try to understand: which of all those things I was used to do were > really necessary and which of them are just boilerplate I need to do > because of my tools are too low level? > > Maybe your experience can help us answer that question. > > >> a.) If current HEAD is same as origin/master >> >> $ git stash (stash away my not finished changes) >> $ vi code.c fix.. >> $ git commit -a -c "subject >> >> long explanation of fix >> reference to bug" >> $ git stash apply (and go back to working on my feature) >> >> > So, why is this better than having a new image with a clean version of > HEAD? > > >> b.) E.g. if I finished n-commits but I am not fully done >> > > For this I would propose a slightly different pattern: > >> >> # store my work >> $ git commit -a -m "Work In Progress hack.." >> > > You can commit, ok... but also you could just save the image with your > work in progress, no need to create a hacky commit. > > >> $ git checkout -b new-feature-branch >> >> # go back to master >> $ git checkout master >> $ git reset --hard origin/master (to restore) >> > > To avoid reset, I would propose to leave master like that and put the new > work in a clean branch, starting on origin/master. > > In git-command-line language it would be: > git checkout -b fix origin/master > > So you create a new branch for your fix out of origin/master, leaving the > original branch untouched. > > >> >> # work on the fix >> $ vi code.c fix.. >> $ git commit -a -c "fix..." >> >> No problems here... just we do not use vi for editing code :) > > >> # go back and continue on my fix >> $ git checkout new-feature-branch >> > $ git rebase origin/master >> $ git reset HEAD^1 >> .. continue to work >> >> Several things here. First, I think that everything is simpler if you > just leave your original branch untouched, so you could re-checkout that > branch without the need for reset and removing hacky commits. But even more > interesting if you agree to have two images one for each task, you just go > back to your first image and everything is just like you left it, including > open windows and whatever task you were doing. I think that is a beautiful > value of Pharo I would not like to loose. > > The only thing left would be to incorporate the fix into this image, right > now we do not support rebase, you would need to merge... but I understand > why one would prefer rebase in this scenario, at some point we will support > both options. > > > So, to sum up. I am not trying to replicate in Pharo the way I used to > work in Javascript... I think that would be silly. Instead, we are trying > to take the good stuff of git into Pharo, but without loosing all the good > stuff of Pharo. >
