On 14 April 2018 at 01:55, Guillermo Polito <guillermopol...@gmail.com> wrote:
> > > On Fri, Apr 13, 2018 at 7:34 PM, Ben Coman <b...@openinworld.com> wrote: > >> >> >> On 14 April 2018 at 01:10, Guillermo Polito <guillermopol...@gmail.com> >> wrote: >> >>> >>> >>> On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman <b...@openinworld.com> wrote: >>> >>>> >>>> >>>> On 13 April 2018 at 23:15, Alistair Grant <akgrant0...@gmail.com> >>>> wrote: >>>> >>>>> On 13 April 2018 at 17:07, Cyril Ferlicot <cyril.ferli...@gmail.com> >>>>> wrote: >>>>> > >>>>> > >>>>> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito < >>>>> guillermopol...@gmail.com> 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 "g...@github.com: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 >>>> (g...@github.com: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 = g...@github.com: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 <g...@github.com:bencoman/pharo >>>> .git>" >>>> and selecting that and clicking <Push> worked!!!! >>>> >>>> https://github.com/bencoman/pharo/tree/21686-Setting-backgro >>>> und-images-doesnt-work-on-Pharo-70 >>>> >>> >>> Esteban is working on adding the add remote to the pull/push windows >>> >>> https://github.com/pharo-vcs/iceberg/issues/624 >>> >>> 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>. >> https://git-scm.com/docs/git-clone >> > > 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 > > https://en.wikipedia.org/wiki/Principle_of_least_astonishment > I agree with the principle. btw its really nice how easy it is to choose which remote to push to. cheers -ben
