Re: [Pharo-users] Pharo 7 - New Iceberg feedback

[Guillermo Polito]

Aaand, I've updated

https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo

On Thu, May 24, 2018 at 11:34 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> https://github.com/pharo-vcs/iceberg/wiki/The-Working-Copy(ies)
> https://github.com/pharo-vcs/iceberg/wiki/Branching-and-Merging
>
> On Thu, May 24, 2018 at 11:30 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>> Hi,
>>
>> I'll take some minutes to provide an answer as detailed as possible to
>> all questions in this mail, and to the ones in the mails before.
>> But first, since I know most people only read the first lines of mails
>> :P, if you find any concrete iceberg issues, please report them in
>>
>> https://github.com/pharo-vcs/iceberg/issues
>>
>> Now, answers inline.
>>
>> On Tue, May 22, 2018 at 5:15 PM, Tim Mackinnon  wrote:
>>
>>> Hi - last night we managed to explore the new contribution process as
>>> well as the new iceberg ui at the U.K. Smalltalk meetup last night.
>>>
>>
>> Cool!
>>
>>
>>>
>>> Not many had seen it before so it was a good test run.
>>>
>>> As an initial comment - we need to invest a small amount of time to get
>>> the right docs in places you expect them as not doing so undoes a lot of
>>> good work -  the Pharo main site that points to old contribution docs (and
>>> doesn’t reference the new ones) must be updated ASAP to keep energy high
>>> (we almost lost a few folks last night by going down the wrong path -
>>> fortunately Cyril piped up on Discord for me - phew).
>>>
>>
>> I know. This is indeed important. I'm trying to get time to make videos,
>> paste as much info in the wiki. Now, it would be good to know what was
>> exactly your "wrong path". The more concrete you are, the easier is to fix
>> it :).
>> I see Pharo contribution page (http://pharo.org/contribute-propose-fix)
>> points to https://github.com/pharo-project/pharo/wiki/Contribute-a-
>> fix-to-Pharo which is outdated. I'll fix it ASAP.
>>
>>
>>>
>>> Armed with the right steps it was straightforward - much easier than the
>>> older slices mechanism (that I never was comfortable with) - so HUGE thanks
>>> for that everyone!
>>>
>>> As we worked through it, the more git seasoned folks were confused why
>>> git status in a terminal wasn’t really showing the same info as iceberg
>>> (I’ll put this in a separate thread to discuss, as it’s an interesting
>>> thought which I’m sure has lively discussion).
>>>
>>
>> Well, this is the discussion in the other thread. If you have read the
>> glosssary (https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary),
>> you will notice that iceberg presents you with two working copies:
>>   - the image working copy
>>   - the disk working copy
>>
>> The disk working copy is what most people know when they use git. The
>> directory where you have your repository, with the files you're modifying.
>>
>> The image working copy represent what is loaded in Pharo. It's important
>> to differentiate them because if I send you an image (or you download it
>> from somewhere) you have code loaded on it. This working copy allows us to
>> track how and where you loaded that code from. That is useful if later on
>> you want to contribute to that project in some way.
>>
>> Then there are other questions:
>>
>> !! Why do we still have a disk working copy?
>>
>> Well, this is not really necessary for iceberg to work. Iceberg could
>> just write source code directly on git's BLOB, as Thierry mentioned in the
>> other thread.
>> The reason for this working copy to be there is just to try to be less
>> alien.
>> Having the disk working copy allows people to still have a way to:
>>   - edit non-smalltalk files from the command like
>>   - use the non command line as a last ressource if something goes wrong
>> with your Pharo image
>>   - use external tools to manage the repository (sourcetree, git kraken,
>> whatever you're confortable with)
>>
>> The idea is that Iceberg will try to keep your disk working copy in sync
>> with your repository HEAD.
>> It will take care of transparently synchronizing your disk working copy
>> when:
>>  - you commit
>>  - you change branches
>>  - you pull/push/merge
>>
>> !! Why don't we dump code into the disk as we write it?
>>
>> The main reason behind it is that the image is not causally connected to
>> the directory in disk, as Ben implied.
>> There is not a 1 to 1 correspondence between what you could ever have in
>> disk and your running image.
>> As Ben mentionned, for this to happen:
>>  - changing the source code in disk should get automatically loaded into
>> Pharo
>>  - changing the source code in Pharo should get automatically written in
>> disk
>>
>> The thing is that this is much more difficult than it sounds:
>>  - What happens if you do not want to save your image, you forgot to save
>> it or it crashes? Suddenly you will have an image that is not in sync with
>> your repository. Would you load all changes into your image as soon 

Re: [Pharo-users] Pharo 7 - New Iceberg feedback

[Guillermo Polito]

https://github.com/pharo-vcs/iceberg/wiki/The-Working-Copy(ies)
https://github.com/pharo-vcs/iceberg/wiki/Branching-and-Merging

On Thu, May 24, 2018 at 11:30 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> Hi,
>
> I'll take some minutes to provide an answer as detailed as possible to all
> questions in this mail, and to the ones in the mails before.
> But first, since I know most people only read the first lines of mails :P,
> if you find any concrete iceberg issues, please report them in
>
> https://github.com/pharo-vcs/iceberg/issues
>
> Now, answers inline.
>
> On Tue, May 22, 2018 at 5:15 PM, Tim Mackinnon  wrote:
>
>> Hi - last night we managed to explore the new contribution process as
>> well as the new iceberg ui at the U.K. Smalltalk meetup last night.
>>
>
> Cool!
>
>
>>
>> Not many had seen it before so it was a good test run.
>>
>> As an initial comment - we need to invest a small amount of time to get
>> the right docs in places you expect them as not doing so undoes a lot of
>> good work -  the Pharo main site that points to old contribution docs (and
>> doesn’t reference the new ones) must be updated ASAP to keep energy high
>> (we almost lost a few folks last night by going down the wrong path -
>> fortunately Cyril piped up on Discord for me - phew).
>>
>
> I know. This is indeed important. I'm trying to get time to make videos,
> paste as much info in the wiki. Now, it would be good to know what was
> exactly your "wrong path". The more concrete you are, the easier is to fix
> it :).
> I see Pharo contribution page (http://pharo.org/contribute-propose-fix)
> points to https://github.com/pharo-project/pharo/wiki/Contribute-
> a-fix-to-Pharo which is outdated. I'll fix it ASAP.
>
>
>>
>> Armed with the right steps it was straightforward - much easier than the
>> older slices mechanism (that I never was comfortable with) - so HUGE thanks
>> for that everyone!
>>
>> As we worked through it, the more git seasoned folks were confused why
>> git status in a terminal wasn’t really showing the same info as iceberg
>> (I’ll put this in a separate thread to discuss, as it’s an interesting
>> thought which I’m sure has lively discussion).
>>
>
> Well, this is the discussion in the other thread. If you have read the
> glosssary (https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary),
> you will notice that iceberg presents you with two working copies:
>   - the image working copy
>   - the disk working copy
>
> The disk working copy is what most people know when they use git. The
> directory where you have your repository, with the files you're modifying.
>
> The image working copy represent what is loaded in Pharo. It's important
> to differentiate them because if I send you an image (or you download it
> from somewhere) you have code loaded on it. This working copy allows us to
> track how and where you loaded that code from. That is useful if later on
> you want to contribute to that project in some way.
>
> Then there are other questions:
>
> !! Why do we still have a disk working copy?
>
> Well, this is not really necessary for iceberg to work. Iceberg could just
> write source code directly on git's BLOB, as Thierry mentioned in the other
> thread.
> The reason for this working copy to be there is just to try to be less
> alien.
> Having the disk working copy allows people to still have a way to:
>   - edit non-smalltalk files from the command like
>   - use the non command line as a last ressource if something goes wrong
> with your Pharo image
>   - use external tools to manage the repository (sourcetree, git kraken,
> whatever you're confortable with)
>
> The idea is that Iceberg will try to keep your disk working copy in sync
> with your repository HEAD.
> It will take care of transparently synchronizing your disk working copy
> when:
>  - you commit
>  - you change branches
>  - you pull/push/merge
>
> !! Why don't we dump code into the disk as we write it?
>
> The main reason behind it is that the image is not causally connected to
> the directory in disk, as Ben implied.
> There is not a 1 to 1 correspondence between what you could ever have in
> disk and your running image.
> As Ben mentionned, for this to happen:
>  - changing the source code in disk should get automatically loaded into
> Pharo
>  - changing the source code in Pharo should get automatically written in
> disk
>
> The thing is that this is much more difficult than it sounds:
>  - What happens if you do not want to save your image, you forgot to save
> it or it crashes? Suddenly you will have an image that is not in sync with
> your repository. Would you load all changes into your image as soon as you
> reopen it? Atomically?
>  - What happens if you share your repository between several images?
>  - Or if suddenly you change your branch from the command line to
> something completely different?
>
> Several of these usecases don't even make sense. So we preferred to choose
> the path of 

Re: [Pharo-users] Pharo 7 - New Iceberg feedback

[Guillermo Polito]

Hi,

I'll take some minutes to provide an answer as detailed as possible to all
questions in this mail, and to the ones in the mails before.
But first, since I know most people only read the first lines of mails :P,
if you find any concrete iceberg issues, please report them in

https://github.com/pharo-vcs/iceberg/issues

Now, answers inline.

On Tue, May 22, 2018 at 5:15 PM, Tim Mackinnon  wrote:

> Hi - last night we managed to explore the new contribution process as well
> as the new iceberg ui at the U.K. Smalltalk meetup last night.
>

Cool!


>
> Not many had seen it before so it was a good test run.
>
> As an initial comment - we need to invest a small amount of time to get
> the right docs in places you expect them as not doing so undoes a lot of
> good work -  the Pharo main site that points to old contribution docs (and
> doesn’t reference the new ones) must be updated ASAP to keep energy high
> (we almost lost a few folks last night by going down the wrong path -
> fortunately Cyril piped up on Discord for me - phew).
>

I know. This is indeed important. I'm trying to get time to make videos,
paste as much info in the wiki. Now, it would be good to know what was
exactly your "wrong path". The more concrete you are, the easier is to fix
it :).
I see Pharo contribution page (http://pharo.org/contribute-propose-fix)
points to
https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo which
is outdated. I'll fix it ASAP.


>
> Armed with the right steps it was straightforward - much easier than the
> older slices mechanism (that I never was comfortable with) - so HUGE thanks
> for that everyone!
>
> As we worked through it, the more git seasoned folks were confused why git
> status in a terminal wasn’t really showing the same info as iceberg (I’ll
> put this in a separate thread to discuss, as it’s an interesting thought
> which I’m sure has lively discussion).
>

Well, this is the discussion in the other thread. If you have read the
glosssary (https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary), you
will notice that iceberg presents you with two working copies:
  - the image working copy
  - the disk working copy

The disk working copy is what most people know when they use git. The
directory where you have your repository, with the files you're modifying.

The image working copy represent what is loaded in Pharo. It's important to
differentiate them because if I send you an image (or you download it from
somewhere) you have code loaded on it. This working copy allows us to track
how and where you loaded that code from. That is useful if later on you
want to contribute to that project in some way.

Then there are other questions:

!! Why do we still have a disk working copy?

Well, this is not really necessary for iceberg to work. Iceberg could just
write source code directly on git's BLOB, as Thierry mentioned in the other
thread.
The reason for this working copy to be there is just to try to be less
alien.
Having the disk working copy allows people to still have a way to:
  - edit non-smalltalk files from the command like
  - use the non command line as a last ressource if something goes wrong
with your Pharo image
  - use external tools to manage the repository (sourcetree, git kraken,
whatever you're confortable with)

The idea is that Iceberg will try to keep your disk working copy in sync
with your repository HEAD.
It will take care of transparently synchronizing your disk working copy
when:
 - you commit
 - you change branches
 - you pull/push/merge

!! Why don't we dump code into the disk as we write it?

The main reason behind it is that the image is not causally connected to
the directory in disk, as Ben implied.
There is not a 1 to 1 correspondence between what you could ever have in
disk and your running image.
As Ben mentionned, for this to happen:
 - changing the source code in disk should get automatically loaded into
Pharo
 - changing the source code in Pharo should get automatically written in
disk

The thing is that this is much more difficult than it sounds:
 - What happens if you do not want to save your image, you forgot to save
it or it crashes? Suddenly you will have an image that is not in sync with
your repository. Would you load all changes into your image as soon as you
reopen it? Atomically?
 - What happens if you share your repository between several images?
 - Or if suddenly you change your branch from the command line to something
completely different?

Several of these usecases don't even make sense. So we preferred to choose
the path of "make it explicit".
Of course, we could do better, we are open to discuss any improvements.
Just take into account that Iceberg did not come from an egg :) we have
thought about many possible scenarios and discussed with a lot of people
before.

!! How does merge work?

First, just for the record, merge works. We even
 - detect fast forward merge avoiding the creation of extra merge commits
 - 

Re: [Pharo-users] Pharo 7 - New Iceberg feedback

[Sean P. DeNigris]

Tim Mackinnon wrote
> Although possibly calling it “Commit…” might make it more obvious that you
> have a chance to review changes and change your mind

+1. This minor change would IMHO make things much more obvious, especially
to people unfamiliar with git…



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Pharo 7 - New Iceberg feedback

[Tim Mackinnon]

The community has invested a lot in a new way of working - I’ve seen the pain, 
but I think it’s both inspiring , a difficult journey but ultimately well worth 
it.

We need to finish this first leg though, but I’m still very proud to be a 
smalltalker ...

Sent from my iPhone

> On 22 May 2018, at 16:18, Sven Van Caekenberghe  wrote:
> 
> Hi Tim,
> 
> Thanks for the detailed/constructive feedback. I am sure it will be helpful.
> 
> Sven
> 
>> On 22 May 2018, at 17:15, Tim Mackinnon  wrote:
>> 
>> Hi - last night we managed to explore the new contribution process as well 
>> as the new iceberg ui at the U.K. Smalltalk meetup last night.
>> 
>> Not many had seen it before so it was a good test run.
>> 
>> As an initial comment - we need to invest a small amount of time to get the 
>> right docs in places you expect them as not doing so undoes a lot of good 
>> work -  the Pharo main site that points to old contribution docs (and 
>> doesn’t reference the new ones) must be updated ASAP to keep energy high (we 
>> almost lost a few folks last night by going down the wrong path - 
>> fortunately Cyril piped up on Discord for me - phew).
>> 
>> Armed with the right steps it was straightforward - much easier than the 
>> older slices mechanism (that I never was comfortable with) - so HUGE thanks 
>> for that everyone!
>> 
>> As we worked through it, the more git seasoned folks were confused why git 
>> status in a terminal wasn’t really showing the same info as iceberg (I’ll 
>> put this in a separate thread to discuss, as it’s an interesting thought 
>> which I’m sure has lively discussion).
>> 
>> Anyway - the new UI does take some getting used to (personally I liked the 
>> compactness of the original Iceberg and its tabs), but when you understand 
>> what the different windows show you - I think it makes sense (and hopefully 
>> is more stable). We all missed having an obvious Diff mechanism - we later 
>> spotted that Commit does show this (Although possibly calling it “Commit…” 
>> might make it more obvious that you have a chance to review changes and 
>> change your mind) - but knowing the size of your change and reviewing them 
>> without any danger of committing something is a useful feature (but maybe a 
>> 2.0 enhancement request?).
>> 
>> One small tweak (which I would PR if I knew how to - would be to swap  the 
>> status and branch columns in the Repository window  to make the status  
>> clearer (the status gets lost as it sqashed against the normally much longer 
>> branch name).  Its a simple change to #initializeRepositoryList but I guess 
>> Iceberg is in a different repository (and not in the instructions for 
>> contirbutions).
>> 
>> We also noticed that if you try to use the “Create Pull Request” menu item, 
>> you can’t if you have 2FA enabled on Github (the recommended setting) as I 
>> guess that ssh protocol doesn’t allow this with an ssh key? So I we should 
>> update the instructions to suggest either using the web ui - or - creating 
>> an app specific login (that doesn’t use 2fa). - I’ll look at how to add that 
>> tweak and send a PR.
>> 
>> 
>> Tim
>> 
>> 
>> Sent from my iPhone
> 
> 

Re: [Pharo-users] Pharo 7 - New Iceberg feedback

[Sven Van Caekenberghe]

Hi Tim,

Thanks for the detailed/constructive feedback. I am sure it will be helpful.

Sven

> On 22 May 2018, at 17:15, Tim Mackinnon  wrote:
> 
> Hi - last night we managed to explore the new contribution process as well as 
> the new iceberg ui at the U.K. Smalltalk meetup last night.
> 
> Not many had seen it before so it was a good test run.
> 
> As an initial comment - we need to invest a small amount of time to get the 
> right docs in places you expect them as not doing so undoes a lot of good 
> work -  the Pharo main site that points to old contribution docs (and doesn’t 
> reference the new ones) must be updated ASAP to keep energy high (we almost 
> lost a few folks last night by going down the wrong path - fortunately Cyril 
> piped up on Discord for me - phew).
> 
> Armed with the right steps it was straightforward - much easier than the 
> older slices mechanism (that I never was comfortable with) - so HUGE thanks 
> for that everyone!
> 
> As we worked through it, the more git seasoned folks were confused why git 
> status in a terminal wasn’t really showing the same info as iceberg (I’ll put 
> this in a separate thread to discuss, as it’s an interesting thought which 
> I’m sure has lively discussion).
> 
> Anyway - the new UI does take some getting used to (personally I liked the 
> compactness of the original Iceberg and its tabs), but when you understand 
> what the different windows show you - I think it makes sense (and hopefully 
> is more stable). We all missed having an obvious Diff mechanism - we later 
> spotted that Commit does show this (Although possibly calling it “Commit…” 
> might make it more obvious that you have a chance to review changes and 
> change your mind) - but knowing the size of your change and reviewing them 
> without any danger of committing something is a useful feature (but maybe a 
> 2.0 enhancement request?).
> 
> One small tweak (which I would PR if I knew how to - would be to swap  the 
> status and branch columns in the Repository window  to make the status  
> clearer (the status gets lost as it sqashed against the normally much longer 
> branch name).  Its a simple change to #initializeRepositoryList but I guess 
> Iceberg is in a different repository (and not in the instructions for 
> contirbutions).
> 
> We also noticed that if you try to use the “Create Pull Request” menu item, 
> you can’t if you have 2FA enabled on Github (the recommended setting) as I 
> guess that ssh protocol doesn’t allow this with an ssh key? So I we should 
> update the instructions to suggest either using the web ui - or - creating an 
> app specific login (that doesn’t use 2fa). - I’ll look at how to add that 
> tweak and send a PR.
> 
> 
> Tim
> 
> 
> Sent from my iPhone