[TechTalk] April 12: GIT with Iceberg

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[TechTalk] April 12: GIT with Iceberg

Marcus Denker-4
Hi,

There next TechTalk will be April 12: GIT with Iceberg

        https://association.pharo.org/event-2797068


A regular chat about Pharo. Happens on Discord.

The Tech talks are open to both members and non-members!

Topic:  GIT with Iceberg. Demo of improved UI

We will send an information to all subscribers some hours before the talk starts.



Reply | Threaded
Open this post in threaded view
|

Re: [TechTalk] April 12: GIT with Iceberg

EstebanLM
more like to present the new UI (it received a complete revamp, so we need to inform about it ;) )

cheers!
Esteban

> On 10 Apr 2018, at 16:34, Marcus Denker <[hidden email]> wrote:
>
> Hi,
>
> There next TechTalk will be April 12: GIT with Iceberg
>
> https://association.pharo.org/event-2797068
>
>
> A regular chat about Pharo. Happens on Discord.
>
> The Tech talks are open to both members and non-members!
>
> Topic:  GIT with Iceberg. Demo of improved UI
>
> We will send an information to all subscribers some hours before the talk starts.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [TechTalk] April 12: GIT with Iceberg

Marcus Denker-4
In reply to this post by Marcus Denker-4
This is today

5:00 PM - 7:00 PM (UTC+02:00)

There is a calendar entry to download at: https://association.pharo.org/event-2797068

> On 10 Apr 2018, at 16:34, Marcus Denker <[hidden email]> wrote:
>
> Hi,
>
> There next TechTalk will be April 12: GIT with Iceberg
>
> https://association.pharo.org/event-2797068
>
>
> A regular chat about Pharo. Happens on Discord.
>
> The Tech talks are open to both members and non-members!
>
> Topic:  GIT with Iceberg. Demo of improved UI
>
> We will send an information to all subscribers some hours before the talk starts.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [TechTalk] April 12: GIT with Iceberg

Stephane Ducasse-3
I will not make it but I really want. Let us know where will be the videos.

Stef

On Thu, Apr 12, 2018 at 9:09 AM, Marcus Denker <[hidden email]> wrote:

> This is today
>
> 5:00 PM - 7:00 PM (UTC+02:00)
>
> There is a calendar entry to download at: https://association.pharo.org/event-2797068
>
>> On 10 Apr 2018, at 16:34, Marcus Denker <[hidden email]> wrote:
>>
>> Hi,
>>
>> There next TechTalk will be April 12: GIT with Iceberg
>>
>>       https://association.pharo.org/event-2797068
>>
>>
>> A regular chat about Pharo. Happens on Discord.
>>
>> The Tech talks are open to both members and non-members!
>>
>> Topic:  GIT with Iceberg. Demo of improved UI
>>
>> We will send an information to all subscribers some hours before the talk starts.
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [TechTalk] April 12: GIT with Iceberg

vonbecmann

On Thu, Apr 12, 2018 at 6:42 AM, Stephane Ducasse <[hidden email]> wrote:
I will not make it but I really want. Let us know where will be the videos.

Stef

On Thu, Apr 12, 2018 at 9:09 AM, Marcus Denker <[hidden email]> wrote:
> This is today
>
> 5:00 PM - 7:00 PM (UTC+02:00)
>
> There is a calendar entry to download at: https://association.pharo.org/event-2797068
>
>> On 10 Apr 2018, at 16:34, Marcus Denker <[hidden email]> wrote:
>>
>> Hi,
>>
>> There next TechTalk will be April 12: GIT with Iceberg
>>
>>       https://association.pharo.org/event-2797068
>>
>>
>> A regular chat about Pharo. Happens on Discord.
>>
>> The Tech talks are open to both members and non-members!
>>
>> Topic:  GIT with Iceberg. Demo of improved UI
>>
>> We will send an information to all subscribers some hours before the talk starts.
>>
>>
>
>




--
Bernardo E.C.

Sent from a cheap desktop computer in South America.
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

Marcus Denker-4
In reply to this post by Marcus Denker-4


On 13 Apr 2018, at 15:04, Andrei Stebakov <[hidden email]> wrote:

Can you make the video available online?


Another question, is there a tutorial on Iceberg?

For the updated UI not yet. From the “how do I commit a PR to Pharo” perspective, I will do next week:
-> an update to the description on the website how to commit to PR
-> Do a short video of how to do contribute to Paro7 (as a replacement of the video tutorial I did).


Marcus

On Thu, Apr 12, 2018, 03:10 Marcus Denker <[hidden email]> wrote:
This is today

5:00 PM - 7:00 PM (UTC+02:00)

There is a calendar entry to download at: https://association.pharo.org/event-2797068

> On 10 Apr 2018, at 16:34, Marcus Denker <[hidden email]> wrote:
>
> Hi,
>
> There next TechTalk will be April 12: GIT with Iceberg
>
>       https://association.pharo.org/event-2797068
>
>
> A regular chat about Pharo. Happens on Discord.
>
> The Tech talks are open to both members and non-members!
>
> Topic:  GIT with Iceberg. Demo of improved UI
>
> We will send an information to all subscribers some hours before the talk starts.
>
>



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

Ben Coman


On 13 April 2018 at 21:14, Marcus Denker <[hidden email]> wrote:


On 13 Apr 2018, at 15:04, Andrei Stebakov <[hidden email]> wrote:

Can you make the video available online?


I like the new "New Repo", particularly additional of GitHub alternative (not that I use them, but options is good)
Could you consider adding here a "Pharo Dev Repo" or "Contribute to Pharo" entry or similar
which presets *everything* required to clone the Pharo repo.  

Later, here you might even go as far as letting uses entry an Issue and pre-create the branch 
that a fix will be submitted on.  But for now... one step at a time.

cheers -ben


IcebergNew-NewRepo.png (40K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

Guillermo Polito


On Fri, Apr 13, 2018 at 4:26 PM, Ben Coman <[hidden email]> wrote:


On 13 April 2018 at 21:14, Marcus Denker <[hidden email]> wrote:


On 13 Apr 2018, at 15:04, Andrei Stebakov <[hidden email]> wrote:

Can you make the video available online?


I like the new "New Repo", particularly additional of GitHub alternative (not that I use them, but options is good)
Could you consider adding here a "Pharo Dev Repo" or "Contribute to Pharo" entry or similar
which presets *everything* required to clone the Pharo repo.  

The thing is that the best way to do it is to clone your own fork... And each one has her/his one.
 

Later, here you might even go as far as letting uses entry an Issue and pre-create the branch 
that a fix will be submitted on.  But for now... one step at a time.

That's already there
 

cheers -ben




--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

CyrilFerlicot

On ven. 13 avr. 2018 at 17:03, Guillermo Polito <[hidden email]> wrote:  

The thing is that the best way to do it is to clone your own fork... And each one has her/his one.
 

What your can do is display the list of forks and ask to select the right one. Then it will create the Pharo repo with the two remotes. 



That's already there
 



--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

--
Cyril Ferlicot
https://ferlicot.fr
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

alistairgrant
On 13 April 2018 at 17:07, Cyril Ferlicot <[hidden email]> wrote:

>
>
> On ven. 13 avr. 2018 at 17:03, Guillermo Polito <[hidden email]> wrote:
>>
>>
>> The thing is that the best way to do it is to clone your own fork... And each one has her/his one.
>>
>
>
> What your can do is display the list of forks and ask to select the right one. Then it will create the Pharo repo with the two remotes.


I was going to suggest prompting for the git username.  You can
substitute it in to:

[hidden email]:{username}/pharo.git

and add upstream (pharo-project).


Cheers,
Alistair

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

Guillermo Polito


On Fri, Apr 13, 2018 at 5:15 PM, Alistair Grant <[hidden email]> wrote:
On 13 April 2018 at 17:07, Cyril Ferlicot <[hidden email]> wrote:
>
>
> On ven. 13 avr. 2018 at 17:03, Guillermo Polito <[hidden email]> wrote:
>>
>>
>> The thing is that the best way to do it is to clone your own fork... And each one has her/his one.
>>
>
>
> What your can do is display the list of forks and ask to select the right one. Then it will create the Pharo repo with the two remotes.


This would be strange. Pharo has 75 forks...
 

I was going to suggest prompting for the git username.  You can
substitute it in to:

[hidden email]:{username}/pharo.git

and add upstream (pharo-project). 

Yes, and if it does not exist we have to use github's API to create the fork...

It's doable... But doing it well will take time:
 - I would like a UI where I explain users what I will do with their git credentials
 - I would like to prevent them that I'm doing a fork before doing it
 - I want to show a good progress bar
 - I want to wait until github's finished with the fork (it's an async operation) before continuing with the process
 - And then, I want that if possible iceberg is well (automatically) tested because there are so many corner cases that it starts to be really complicated to do it manually.

But also our plate is full with other things, and we have to prioritize...

If someone wants to give it a try, I can give a hand, review, test, advice...
 


Cheers,
Alistair




--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

alistairgrant
Hi Guille,

On 13 April 2018 at 17:29, Guillermo Polito <[hidden email]> wrote:

>
>
> On Fri, Apr 13, 2018 at 5:15 PM, Alistair Grant <[hidden email]>
> wrote:
>>
>> On 13 April 2018 at 17:07, Cyril Ferlicot <[hidden email]>
>> wrote:
>> >
>> >
>> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito
>> > <[hidden email]> wrote:
>> >>
>> >>
>> >> The thing is that the best way to do it is to clone your own fork...
>> >> And each one has her/his one.
>> >>
>> >
>> >
>> > What your can do is display the list of forks and ask to select the
>> > right one. Then it will create the Pharo repo with the two remotes.
>>
>
> This would be strange. Pharo has 75 forks...
>
>>
>>
>> I was going to suggest prompting for the git username.  You can
>> substitute it in to:
>>
>> [hidden email]:{username}/pharo.git
>>
>> and add upstream (pharo-project).
>
>
> Yes, and if it does not exist we have to use github's API to create the
> fork...

I hadn't even thought of this, I was assuming that the fork had
already been created.

I still think this would be useful, especially for regular
contributors who like to start with a clean image when development a
PR.


> It's doable... But doing it well will take time:
>  - I would like a UI where I explain users what I will do with their git
> credentials
>  - I would like to prevent them that I'm doing a fork before doing it
>  - I want to show a good progress bar
>  - I want to wait until github's finished with the fork (it's an async
> operation) before continuing with the process
>  - And then, I want that if possible iceberg is well (automatically) tested
> because there are so many corner cases that it starts to be really
> complicated to do it manually.
>
> But also our plate is full with other things, and we have to prioritize...
>
> If someone wants to give it a try, I can give a hand, review, test,
> advice...

Fair enough.

Would you be willing to accept a patch that requires an existing fork?

Cheers,
Alistair

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

Guillermo Polito


On Fri, Apr 13, 2018 at 5:38 PM, Alistair Grant <[hidden email]> wrote:
Hi Guille,

On 13 April 2018 at 17:29, Guillermo Polito <[hidden email]> wrote:
>
>
> On Fri, Apr 13, 2018 at 5:15 PM, Alistair Grant <[hidden email]>
> wrote:
>>
>> On 13 April 2018 at 17:07, Cyril Ferlicot <[hidden email]>
>> wrote:
>> >
>> >
>> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito
>> > <[hidden email]> wrote:
>> >>
>> >>
>> >> The thing is that the best way to do it is to clone your own fork...
>> >> And each one has her/his one.
>> >>
>> >
>> >
>> > What your can do is display the list of forks and ask to select the
>> > right one. Then it will create the Pharo repo with the two remotes.
>>
>
> This would be strange. Pharo has 75 forks...
>
>>
>>
>> I was going to suggest prompting for the git username.  You can
>> substitute it in to:
>>
>> [hidden email]:{username}/pharo.git
>>
>> and add upstream (pharo-project).
>
>
> Yes, and if it does not exist we have to use github's API to create the
> fork...

I hadn't even thought of this, I was assuming that the fork had
already been created.

I still think this would be useful, especially for regular
contributors who like to start with a clean image when development a
PR.


> It's doable... But doing it well will take time:
>  - I would like a UI where I explain users what I will do with their git
> credentials
>  - I would like to prevent them that I'm doing a fork before doing it
>  - I want to show a good progress bar
>  - I want to wait until github's finished with the fork (it's an async
> operation) before continuing with the process
>  - And then, I want that if possible iceberg is well (automatically) tested
> because there are so many corner cases that it starts to be really
> complicated to do it manually.
>
> But also our plate is full with other things, and we have to prioritize...
>
> If someone wants to give it a try, I can give a hand, review, test,
> advice...

Fair enough.

Would you be willing to accept a patch that requires an existing fork?

Of course good is better than perfect :)


I've worked yesterday and this morning to have iceberg's ci green and working for PRs also. I've enhanced included a couple of new tests.
 

Cheers,
Alistair




--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

Ben Coman
In reply to this post by alistairgrant


On 13 April 2018 at 23:15, Alistair Grant <[hidden email]> wrote:
On 13 April 2018 at 17:07, Cyril Ferlicot <[hidden email]> wrote:
>
>
> On ven. 13 avr. 2018 at 17:03, Guillermo Polito <[hidden email]> wrote:
>>
>>
>> The thing is that the best way to do it is to clone your own fork... And each one has her/his one.

I know, but momentarily forgot while trying to work on my first Issue with the new UI.
However I discovered something cool...

I had directly cloned "[hidden email]:pharo-project/pharo.git"
successfully brought that "Up to date"
then in the "Working copy of pharo" window, clicked <New Issue> and filled in details,
made my code change,
then clicked <Commit>
then clicked <Push> bringing me to a window titled "Push pharo/21686-.../21686..."
where the only option to "Push to remote: " was  "origin ([hidden email]:pharo-project/pharo.git)"
and clicking <Push> of course produced an error "LGit_GIT_EEOF: ERROR: Permission to pharo-project/pharo.git denied to bencoman."
Fair enough!

But then...!!!
Back in the "Repositories" window,
"pharo" > right-click > Repository > Add Remote
   Remote name = bencoman
   Remote URL = [hidden email]:pharo-project/pharo.git
And back in the "Working copy of pharo" window
clicked <Push>  bringing again me to a window titled "Push pharo/21686-.../21686..."
but now I had an extra option "bencoman <[hidden email]:bencoman/pharo.git>"
and selecting that and clicking  <Push> worked!!!!


Now the key thing here is that I **didn't** have to first 
synchronise  github.com:bencoman/pharo.git  with  github.com:pharo-project/pharo.git
and remember to clone  github.com: bencoman/pharo.git .
I just pushed to my repo **after-the-fact**.

I haven't submitted many fixes lately to get familiar with Iceberg,
and maybe I missed something in the old workflow, 
but previously it seemed that my pharo github repo needed to be up to date, 
and I must clone from there.

The new UI is intuitive and made it east to clone from pharo-project, make fix the push to bencoman.
I worked this out from just a small bit of trial & error.


One request...
In attached snapshot where the remotes show "origin", 
please consider showing that as "pharo-project"
The term "origin" is useful for generic documentation and for examples,
but there is *nothing* special about that label from a git perspective.
A remote is a remote is a remote.

Since mostly pharo development workflow will follow a triangle, 
from remote pharo-project repo, to remote personal repo, PR to remote pharo-project repo,
it would be more useful conceptually 
to have the pharo-project remote labelled "pharo-project" rather than labelled "origin".

cheers -ben

 
>>
>
>
> What your can do is display the list of forks and ask to select the right one. Then it will create the Pharo repo with the two remotes.


I was going to suggest prompting for the git username.  You can
substitute it in to:

[hidden email]:{username}/pharo.git

and add upstream (pharo-project).


Cheers,
Alistair



IcebergNew-Remotes.png (130K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

Guillermo Polito


On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman <[hidden email]> wrote:


On 13 April 2018 at 23:15, Alistair Grant <[hidden email]> wrote:
On 13 April 2018 at 17:07, Cyril Ferlicot <[hidden email]> wrote:
>
>
> On ven. 13 avr. 2018 at 17:03, Guillermo Polito <[hidden email]> wrote:
>>
>>
>> The thing is that the best way to do it is to clone your own fork... And each one has her/his one.

I know, but momentarily forgot while trying to work on my first Issue with the new UI.
However I discovered something cool...

I had directly cloned "[hidden email]:pharo-project/pharo.git"
successfully brought that "Up to date"
then in the "Working copy of pharo" window, clicked <New Issue> and filled in details,
made my code change,
then clicked <Commit>
then clicked <Push> bringing me to a window titled "Push pharo/21686-.../21686..."
where the only option to "Push to remote: " was  "origin ([hidden email]:pharo-project/pharo.git)"
and clicking <Push> of course produced an error "LGit_GIT_EEOF: ERROR: Permission to pharo-project/pharo.git denied to bencoman."
Fair enough!

Have to gracefully manage that error. Could you open an issue?
 

But then...!!!
Back in the "Repositories" window,
"pharo" > right-click > Repository > Add Remote
   Remote name = bencoman
   Remote URL = [hidden email]:pharo-project/pharo.git
And back in the "Working copy of pharo" window
clicked <Push>  bringing again me to a window titled "Push pharo/21686-.../21686..."
but now I had an extra option "bencoman <[hidden email]:bencoman/pharo.git>"
and selecting that and clicking  <Push> worked!!!!


Esteban is working on adding the add remote to the pull/push windows


so you will have less clicks to do there ;)
 


Now the key thing here is that I **didn't** have to first 
synchronise  github.com:bencoman/pharo.git  with  github.com:pharo-project/pharo.git
and remember to clone  github.com: bencoman/pharo.git .
I just pushed to my repo **after-the-fact**.

I haven't submitted many fixes lately to get familiar with Iceberg,
and maybe I missed something in the old workflow, 
but previously it seemed that my pharo github repo needed to be up to date, 
and I must clone from there.

Well, it depends.

Scenario 1) If you're not planning to reuse your clone, you don't need to care about synchronize.
 - just reclone pharo from pharo
 - add your fork as remote
 - you're set

Scenario 2) If you want to reuse your clone you may not synchronize them.
 - pull from pharo from time to time
 - start a new branch from the current commit
 - you're set

But then, there is people that may want/need to have some other workflow. For example:
 - I start from scenario 1
 - make a branch
 - commit some work
 - tomorrow I come back and I download a new image
    * a couple of integrations may have happened in between!!
    * but I want to continue working in my branch
 
Then the scenario could be solved as:
 - fetch from pharo
 - if you're in detached mode, just use the merge image into branch action and select your branch
 - or if you want to do it manually:
   - checkout your branch in your image without loading packages
   - merge pharo/development into your branch
 - continue working

Now, what I would like is that we detect such "common rough scenarios" and discuss how we could have a better UI support for them.
Maybe we need as a part of the Pharo plugin a wizard that takes you through the "synchronize my image again please"?
Or could it be solved with some strategy that is general enough to be reused in any repository?
 

The new UI is intuitive and made it east to clone from pharo-project, make fix the push to bencoman.
I worked this out from just a small bit of trial & error.


One request...
In attached snapshot where the remotes show "origin", 
please consider showing that as "pharo-project"
The term "origin" is useful for generic documentation and for examples,
but there is *nothing* special about that label from a git perspective.
A remote is a remote is a remote.

Well that's mostly a libgit thing. It does it by default I think when you clone, and I'm pretty sure that a lot of people would be against breaking such default because that's how git works also.
What could maybe be done is to enhance the "New repository" dialog to be able to provide a remote name using origin by default?
Like that people could be able to override it to their convenience?
 

Since mostly pharo development workflow will follow a triangle, 
from remote pharo-project repo, to remote personal repo, PR to remote pharo-project repo,
it would be more useful conceptually 
to have the pharo-project remote labelled "pharo-project" rather than labelled "origin".

cheers -ben

 
>>
>
>
> What your can do is display the list of forks and ask to select the right one. Then it will create the Pharo repo with the two remotes.


I was going to suggest prompting for the git username.  You can
substitute it in to:

[hidden email]:{username}/pharo.git

and add upstream (pharo-project).


Cheers,
Alistair





--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

Ben Coman


On 14 April 2018 at 01:10, Guillermo Polito <[hidden email]> wrote:


On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman <[hidden email]> wrote:


On 13 April 2018 at 23:15, Alistair Grant <[hidden email]> wrote:
On 13 April 2018 at 17:07, Cyril Ferlicot <[hidden email]> wrote:
>
>
> On ven. 13 avr. 2018 at 17:03, Guillermo Polito <[hidden email]> wrote:
>>
>>
>> The thing is that the best way to do it is to clone your own fork... And each one has her/his one.

I know, but momentarily forgot while trying to work on my first Issue with the new UI.
However I discovered something cool...

I had directly cloned "[hidden email]:pharo-project/pharo.git"
successfully brought that "Up to date"
then in the "Working copy of pharo" window, clicked <New Issue> and filled in details,
made my code change,
then clicked <Commit>
then clicked <Push> bringing me to a window titled "Push pharo/21686-.../21686..."
where the only option to "Push to remote: " was  "origin ([hidden email]:pharo-project/pharo.git)"
and clicking <Push> of course produced an error "LGit_GIT_EEOF: ERROR: Permission to pharo-project/pharo.git denied to bencoman."
Fair enough!

Have to gracefully manage that error. Could you open an issue?
 

But then...!!!
Back in the "Repositories" window,
"pharo" > right-click > Repository > Add Remote
   Remote name = bencoman
   Remote URL = [hidden email]:pharo-project/pharo.git
And back in the "Working copy of pharo" window
clicked <Push>  bringing again me to a window titled "Push pharo/21686-.../21686..."
but now I had an extra option "bencoman <[hidden email]:bencoman/pharo.git>"
and selecting that and clicking  <Push> worked!!!!


Esteban is working on adding the add remote to the pull/push windows


so you will have less clicks to do there ;)
 


Now the key thing here is that I **didn't** have to first 
synchronise  github.com:bencoman/pharo.git  with  github.com:pharo-project/pharo.git
and remember to clone  github.com: bencoman/pharo.git .
I just pushed to my repo **after-the-fact**.

I haven't submitted many fixes lately to get familiar with Iceberg,
and maybe I missed something in the old workflow, 
but previously it seemed that my pharo github repo needed to be up to date, 
and I must clone from there.

Well, it depends.

Scenario 1) If you're not planning to reuse your clone, you don't need to care about synchronize.
 - just reclone pharo from pharo
 - add your fork as remote
 - you're set

Scenario 2) If you want to reuse your clone you may not synchronize them.
 - pull from pharo from time to time
 - start a new branch from the current commit
 - you're set

But then, there is people that may want/need to have some other workflow. For example:
 - I start from scenario 1
 - make a branch
 - commit some work
 - tomorrow I come back and I download a new image
    * a couple of integrations may have happened in between!!
    * but I want to continue working in my branch
 
Then the scenario could be solved as:
 - fetch from pharo
 - if you're in detached mode, just use the merge image into branch action and select your branch
 - or if you want to do it manually:
   - checkout your branch in your image without loading packages
   - merge pharo/development into your branch
 - continue working

Now, what I would like is that we detect such "common rough scenarios" and discuss how we could have a better UI support for them.
Maybe we need as a part of the Pharo plugin a wizard that takes you through the "synchronize my image again please"?
Or could it be solved with some strategy that is general enough to be reused in any repository?
 

The new UI is intuitive and made it east to clone from pharo-project, make fix the push to bencoman.
I worked this out from just a small bit of trial & error.


One request...
In attached snapshot where the remotes show "origin", 
please consider showing that as "pharo-project"
The term "origin" is useful for generic documentation and for examples,
but there is *nothing* special about that label from a git perspective.
A remote is a remote is a remote.

Well that's mostly a libgit thing. It does it by default I think when you clone, and I'm pretty sure that a lot of people would be against breaking such default because that's how git works also.

Its not "the" way git works.  Its just the "default".   
Any name can be used to refer to the upstream repo.
i.e...
  --origin <name>
       Instead of using the remote name origin to keep track of the upstream repository, use <name>.

but never-mind, you've got bigger fish to fry :)
cheers -ben

 
What could maybe be done is to enhance the "New repository" dialog to be able to provide a remote name using origin by default?
Like that people could be able to override it to their convenience?
 

Since mostly pharo development workflow will follow a triangle, 
from remote pharo-project repo, to remote personal repo, PR to remote pharo-project repo,
it would be more useful conceptually 
to have the pharo-project remote labelled "pharo-project" rather than labelled "origin".
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

Guillermo Polito


On Fri, Apr 13, 2018 at 7:34 PM, Ben Coman <[hidden email]> wrote:


On 14 April 2018 at 01:10, Guillermo Polito <[hidden email]> wrote:


On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman <[hidden email]> wrote:


On 13 April 2018 at 23:15, Alistair Grant <[hidden email]> wrote:
On 13 April 2018 at 17:07, Cyril Ferlicot <[hidden email]> wrote:
>
>
> On ven. 13 avr. 2018 at 17:03, Guillermo Polito <[hidden email]> wrote:
>>
>>
>> The thing is that the best way to do it is to clone your own fork... And each one has her/his one.

I know, but momentarily forgot while trying to work on my first Issue with the new UI.
However I discovered something cool...

I had directly cloned "[hidden email]:pharo-project/pharo.git"
successfully brought that "Up to date"
then in the "Working copy of pharo" window, clicked <New Issue> and filled in details,
made my code change,
then clicked <Commit>
then clicked <Push> bringing me to a window titled "Push pharo/21686-.../21686..."
where the only option to "Push to remote: " was  "origin ([hidden email]:pharo-project/pharo.git)"
and clicking <Push> of course produced an error "LGit_GIT_EEOF: ERROR: Permission to pharo-project/pharo.git denied to bencoman."
Fair enough!

Have to gracefully manage that error. Could you open an issue?
 

But then...!!!
Back in the "Repositories" window,
"pharo" > right-click > Repository > Add Remote
   Remote name = bencoman
   Remote URL = [hidden email]:pharo-project/pharo.git
And back in the "Working copy of pharo" window
clicked <Push>  bringing again me to a window titled "Push pharo/21686-.../21686..."
but now I had an extra option "bencoman <[hidden email]:bencoman/pharo.git>"
and selecting that and clicking  <Push> worked!!!!


Esteban is working on adding the add remote to the pull/push windows


so you will have less clicks to do there ;)
 


Now the key thing here is that I **didn't** have to first 
synchronise  github.com:bencoman/pharo.git  with  github.com:pharo-project/pharo.git
and remember to clone  github.com: bencoman/pharo.git .
I just pushed to my repo **after-the-fact**.

I haven't submitted many fixes lately to get familiar with Iceberg,
and maybe I missed something in the old workflow, 
but previously it seemed that my pharo github repo needed to be up to date, 
and I must clone from there.

Well, it depends.

Scenario 1) If you're not planning to reuse your clone, you don't need to care about synchronize.
 - just reclone pharo from pharo
 - add your fork as remote
 - you're set

Scenario 2) If you want to reuse your clone you may not synchronize them.
 - pull from pharo from time to time
 - start a new branch from the current commit
 - you're set

But then, there is people that may want/need to have some other workflow. For example:
 - I start from scenario 1
 - make a branch
 - commit some work
 - tomorrow I come back and I download a new image
    * a couple of integrations may have happened in between!!
    * but I want to continue working in my branch
 
Then the scenario could be solved as:
 - fetch from pharo
 - if you're in detached mode, just use the merge image into branch action and select your branch
 - or if you want to do it manually:
   - checkout your branch in your image without loading packages
   - merge pharo/development into your branch
 - continue working

Now, what I would like is that we detect such "common rough scenarios" and discuss how we could have a better UI support for them.
Maybe we need as a part of the Pharo plugin a wizard that takes you through the "synchronize my image again please"?
Or could it be solved with some strategy that is general enough to be reused in any repository?
 

The new UI is intuitive and made it east to clone from pharo-project, make fix the push to bencoman.
I worked this out from just a small bit of trial & error.


One request...
In attached snapshot where the remotes show "origin", 
please consider showing that as "pharo-project"
The term "origin" is useful for generic documentation and for examples,
but there is *nothing* special about that label from a git perspective.
A remote is a remote is a remote.

Well that's mostly a libgit thing. It does it by default I think when you clone, and I'm pretty sure that a lot of people would be against breaking such default because that's how git works also.

Its not "the" way git works.  Its just the "default".   
Any name can be used to refer to the upstream repo.
i.e...
  --origin <name>
       Instead of using the remote name origin to keep track of the upstream repository, use <name>.

I know it's the default name git gives by default :). But changing that may confuse people that are used to git also...
So I'm just thinking what would be the less surprising thing for most of the people



but never-mind, you've got bigger fish to fry :)
 
cheers -ben

 
What could maybe be done is to enhance the "New repository" dialog to be able to provide a remote name using origin by default?
Like that people could be able to override it to their convenience?
 

Since mostly pharo development workflow will follow a triangle, 
from remote pharo-project repo, to remote personal repo, PR to remote pharo-project repo,
it would be more useful conceptually 
to have the pharo-project remote labelled "pharo-project" rather than labelled "origin".



--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

Ben Coman


On 14 April 2018 at 01:55, Guillermo Polito <[hidden email]> wrote:


On Fri, Apr 13, 2018 at 7:34 PM, Ben Coman <[hidden email]> wrote:


On 14 April 2018 at 01:10, Guillermo Polito <[hidden email]> wrote:


On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman <[hidden email]> wrote:


On 13 April 2018 at 23:15, Alistair Grant <[hidden email]> wrote:
On 13 April 2018 at 17:07, Cyril Ferlicot <[hidden email]> wrote:
>
>
> On ven. 13 avr. 2018 at 17:03, Guillermo Polito <[hidden email]> wrote:
>>
>>
>> The thing is that the best way to do it is to clone your own fork... And each one has her/his one.

I know, but momentarily forgot while trying to work on my first Issue with the new UI.
However I discovered something cool...

I had directly cloned "[hidden email]:pharo-project/pharo.git"
successfully brought that "Up to date"
then in the "Working copy of pharo" window, clicked <New Issue> and filled in details,
made my code change,
then clicked <Commit>
then clicked <Push> bringing me to a window titled "Push pharo/21686-.../21686..."
where the only option to "Push to remote: " was  "origin ([hidden email]:pharo-project/pharo.git)"
and clicking <Push> of course produced an error "LGit_GIT_EEOF: ERROR: Permission to pharo-project/pharo.git denied to bencoman."
Fair enough!

Have to gracefully manage that error. Could you open an issue?
 

But then...!!!
Back in the "Repositories" window,
"pharo" > right-click > Repository > Add Remote
   Remote name = bencoman
   Remote URL = [hidden email]:pharo-project/pharo.git
And back in the "Working copy of pharo" window
clicked <Push>  bringing again me to a window titled "Push pharo/21686-.../21686..."
but now I had an extra option "bencoman <[hidden email]:bencoman/pharo.git>"
and selecting that and clicking  <Push> worked!!!!


Esteban is working on adding the add remote to the pull/push windows


so you will have less clicks to do there ;)
 


Now the key thing here is that I **didn't** have to first 
synchronise  github.com:bencoman/pharo.git  with  github.com:pharo-project/pharo.git
and remember to clone  github.com: bencoman/pharo.git .
I just pushed to my repo **after-the-fact**.

I haven't submitted many fixes lately to get familiar with Iceberg,
and maybe I missed something in the old workflow, 
but previously it seemed that my pharo github repo needed to be up to date, 
and I must clone from there.

Well, it depends.

Scenario 1) If you're not planning to reuse your clone, you don't need to care about synchronize.
 - just reclone pharo from pharo
 - add your fork as remote
 - you're set

Scenario 2) If you want to reuse your clone you may not synchronize them.
 - pull from pharo from time to time
 - start a new branch from the current commit
 - you're set

But then, there is people that may want/need to have some other workflow. For example:
 - I start from scenario 1
 - make a branch
 - commit some work
 - tomorrow I come back and I download a new image
    * a couple of integrations may have happened in between!!
    * but I want to continue working in my branch
 
Then the scenario could be solved as:
 - fetch from pharo
 - if you're in detached mode, just use the merge image into branch action and select your branch
 - or if you want to do it manually:
   - checkout your branch in your image without loading packages
   - merge pharo/development into your branch
 - continue working

Now, what I would like is that we detect such "common rough scenarios" and discuss how we could have a better UI support for them.
Maybe we need as a part of the Pharo plugin a wizard that takes you through the "synchronize my image again please"?
Or could it be solved with some strategy that is general enough to be reused in any repository?
 

The new UI is intuitive and made it east to clone from pharo-project, make fix the push to bencoman.
I worked this out from just a small bit of trial & error.


One request...
In attached snapshot where the remotes show "origin", 
please consider showing that as "pharo-project"
The term "origin" is useful for generic documentation and for examples,
but there is *nothing* special about that label from a git perspective.
A remote is a remote is a remote.

Well that's mostly a libgit thing. It does it by default I think when you clone, and I'm pretty sure that a lot of people would be against breaking such default because that's how git works also.

Its not "the" way git works.  Its just the "default".   
Any name can be used to refer to the upstream repo.
i.e...
  --origin <name>
       Instead of using the remote name origin to keep track of the upstream repository, use <name>.

I know it's the default name git gives by default :). But changing that may confuse people that are used to git also...
So I'm just thinking what would be the less surprising thing for most of the people


 I agree with the principle.
btw its really nice how easy it is to choose which remote to push to.

cheers -ben