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