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.

Reply via email to