On Fri, Apr 13, 2018 at 7:34 PM, Ben Coman <btc@openinworld.com> wrote:

On 14 April 2018 at 01:10, Guillermo Polito <guillermopolito@gmail.com> wrote:

On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman <btc@openinworld.com> wrote:

On 13 April 2018 at 23:15, Alistair Grant <akgrant0710@gmail.com> wrote:

On 13 April 2018 at 17:07, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
>
>
> On ven. 13 avr. 2018 at 17:03, Guillermo Polito <guillermopolito@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 "git@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 (git@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 =��git@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 <git@github.com:bencoman/pharo.git>"

and selecting that and clicking�� <Push> worked!!!!

https://github.com/bencoman/pharo/tree/21686-Setting-background-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