Re: [Pharo-users] Iceberg and git workflow

[Nicolas Passerini]

No I do not know it, how does it work?

On Mon, Oct 3, 2016 at 3:43 PM, Vitor Medina Cruz 
wrote:

> Yes, I agree on the case of fake commit, I prefer your usage of git. In
> the case of stash, I prefer Intellij shelve feature, do you know it? I
> think it helps me organize better than the stash, I use it all the time.
>
> On Mon, Oct 3, 2016 at 10:35 AM, Nicolas Passerini 
> wrote:
>
>>
>>
>> On Mon, Oct 3, 2016 at 2:19 PM, Vitor Medina Cruz 
>> wrote:
>>
>>> 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?
>>>
>>>
>> Just one comment: the proposal is not to have an image for each branch,
>> you can switch branches using Iceberg. What Iceberg does support not
>> currently is just the "stash" command.
>>
>> Yet it could be slower to create a clean image with your changes, there
>> are ways to make it faster. Also git stash has its own problems, personally
>> I am not a fun of that feature, and I've seen lots of time people messing
>> with it and loosing changes. Moreover, I do not see that saving a "fake"
>> commit to later delete it as a "best practice", but more as a workaround
>> because you do not have a better tool.
>>
>> For all this grounds is that we do not see it as a priority, because we
>> think that there are other tools that can replace it (yet we would like to
>> listen to other opinions) .
>>
>
>

Re: [Pharo-users] Iceberg and git workflow

[Vitor Medina Cruz]

Yes, I agree on the case of fake commit, I prefer your usage of git. In the
case of stash, I prefer Intellij shelve feature, do you know it? I think it
helps me organize better than the stash, I use it all the time.

On Mon, Oct 3, 2016 at 10:35 AM, Nicolas Passerini 
wrote:

>
>
> On Mon, Oct 3, 2016 at 2:19 PM, Vitor Medina Cruz 
> wrote:
>
>> 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?
>>
>>
> Just one comment: the proposal is not to have an image for each branch,
> you can switch branches using Iceberg. What Iceberg does support not
> currently is just the "stash" command.
>
> Yet it could be slower to create a clean image with your changes, there
> are ways to make it faster. Also git stash has its own problems, personally
> I am not a fun of that feature, and I've seen lots of time people messing
> with it and loosing changes. Moreover, I do not see that saving a "fake"
> commit to later delete it as a "best practice", but more as a workaround
> because you do not have a better tool.
>
> For all this grounds is that we do not see it as a priority, because we
> think that there are other tools that can replace it (yet we would like to
> listen to other opinions) .
>

Re: [Pharo-users] Iceberg and git workflow

[Nicolas Passerini]

On Mon, Oct 3, 2016 at 2:19 PM, Vitor Medina Cruz 
wrote:

> 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?
>
>
Just one comment: the proposal is not to have an image for each branch, you
can switch branches using Iceberg. What Iceberg does support not currently
is just the "stash" command.

Yet it could be slower to create a clean image with your changes, there are
ways to make it faster. Also git stash has its own problems, personally I
am not a fun of that feature, and I've seen lots of time people messing
with it and loosing changes. Moreover, I do not see that saving a "fake"
commit to later delete it as a "best practice", but more as a workaround
because you do not have a better tool.

For all this grounds is that we do not see it as a priority, because we
think that there are other tools that can replace it (yet we would like to
listen to other opinions) .

Re: [Pharo-users] Iceberg and git workflow

[Vitor Medina Cruz]

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 
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.
>

Re: [Pharo-users] Iceberg and git workflow

[Nicolas Passerini]

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.

Re: [Pharo-users] Iceberg and git workflow

[Christophe Demarey]

> Le 12 sept. 2016 à 22:20, Stephan Eggermont  a écrit :
> 
> On 12/09/16 21:51, Christophe Demarey wrote:
>> I think your scenario is not covered by Iceberg. It could be a nice feature 
>> but not one of the most important.
> 
> Why do you think so?

In my mind, the top priorities are to have a UI allowing to easily:
- clone a repository
- sync with a remote
- a good diff and merge support
- an easy way to understand the project history (among all branches): log, 
visual graph of branches and versions
- choose what you want to commit (even if we do not use git index)
- easy switch to another tag, branch
(- and use of libgit instead of gitfiletree: important for windows users)

I see git stash usage less important than this one. But maybe it is a 
top-priority feature for some people heavily relying on it.
Anyway, the best way is to play/use Iceberg and give feedback to Nicolas about 
what is good, what could be improved / added. We just need to take care that 
Nicolas has limited time and, at some point, we need to take decisions.

Re: [Pharo-users] Iceberg and git workflow

[Stephan Eggermont]

On 12/09/16 21:51, Christophe Demarey wrote:

I think your scenario is not covered by Iceberg. It could be a nice feature but 
not one of the most important.


Why do you think so?

Stephan

Re: [Pharo-users] Iceberg and git workflow

[Christophe Demarey]

Hi Holger,

I think your scenario is not covered by Iceberg. It could be a nice feature but 
not one of the most important. Nicolas will answer but I think he focuses on 
most common scenarios.
In my case, what I miss is to be able to choose what I want to commit. Nicolas 
already planned to add this.

Christophe

> Le 12 sept. 2016 à 16:15, Holger Freyther  a écrit :
> 
> Hi,
> 
> I am a heavy git user with languages like C, C++, Python, Ruby and even GNU 
> Smalltalk and I hope iceberg will bring the same powerful experience to Pharo.
> 
> Last Friday I started to add a bigger refactoring for a new feature to my 
> software and didn't finish. Sadly today an issue in the code was found and I 
> would like to fix this before fixing my code. I use this as opportunity to 
> ask if Iceberg has some answers for that.
> 
> 
> With a non-Pharo project I would do:
> 
> 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)
> 
> 
> b.) E.g. if I finished n-commits but I am not fully done
> 
> # store my work
> $ git commit -a -m "Work In Progress hack.."
> $ git checkout -b new-feature-branch
> 
> # go back to master
> $ git checkout master 
> $ git reset --hard origin/master (to restore)
> 
> # work on the fix
> $ vi code.c fix..
> $ git commit -a -c "fix..."
> 
> # go back and continue on my fix
> $ git checkout new-feature-branch
> $ git rebase origin/master
> $ git reset HEAD^1
> .. continue to work
> 
> 
> 

Re: [Pharo-users] Iceberg and git workflow

[stepharo]

Hi Holger

I will let nicolas reply detail.

Now Iceberg is not equals to git.
For that you can already take gitfiletree (whatever is its name) and 
your command line tool and do what you want.
What would be the reason to duplicate git in Pharo? Exposing all the 
complexity of git to pharo?


Iceberg is an abstraction over a distribution source versioning system 
looking like git.

And it offers a process and workflow to manage projects stored in git.
Now iceberg should cover main and common scenario.
And one complex scenario we have is how to manage changes that cross cut 
several projects (pharo / RB / GT...).


Stef


Hi,

I am a heavy git user with languages like C, C++, Python, Ruby and even GNU 
Smalltalk and I hope iceberg will bring the same powerful experience to Pharo.

Last Friday I started to add a bigger refactoring for a new feature to my 
software and didn't finish. Sadly today an issue in the code was found and I 
would like to fix this before fixing my code. I use this as opportunity to ask 
if Iceberg has some answers for that.


With a non-Pharo project I would do:

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)


b.) E.g. if I finished n-commits but I am not fully done

# store my work
$ git commit -a -m "Work In Progress hack.."
$ git checkout -b new-feature-branch

# go back to master
$ git checkout master
$ git reset --hard origin/master (to restore)

# work on the fix
$ vi code.c fix..
$ git commit -a -c "fix..."

# go back and continue on my fix
$ git checkout new-feature-branch
$ git rebase origin/master
$ git reset HEAD^1
.. continue to work

[Pharo-users] Iceberg and git workflow

[Holger Freyther]

Hi,

I am a heavy git user with languages like C, C++, Python, Ruby and even GNU 
Smalltalk and I hope iceberg will bring the same powerful experience to Pharo.

Last Friday I started to add a bigger refactoring for a new feature to my 
software and didn't finish. Sadly today an issue in the code was found and I 
would like to fix this before fixing my code. I use this as opportunity to ask 
if Iceberg has some answers for that.


With a non-Pharo project I would do:

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)


b.) E.g. if I finished n-commits but I am not fully done

# store my work
$ git commit -a -m "Work In Progress hack.."
$ git checkout -b new-feature-branch

# go back to master
$ git checkout master 
$ git reset --hard origin/master (to restore)

# work on the fix
$ vi code.c fix..
$ git commit -a -c "fix..."

# go back and continue on my fix
$ git checkout new-feature-branch
$ git rebase origin/master
$ git reset HEAD^1
.. continue to work