[Pharo-users] Iceberg working with forks - can it be easier?
guillermopolito at gmail.com
Mon Feb 18 03:56:53 EST 2019
On Fri, Feb 15, 2019 at 7:06 PM Tim Mackinnon <tim at testit.works> wrote:
> Hi guys - I’ve spent a few hours scratching my head trying to understand
> why some of my Pull Requests to a project I had forked kept showing my
> previous commits when I thought I was all caught up.
> It suddenly dawned on me, that when I had forked, and then done some work
> and then submitted a PR, and then applied it upstream that my fork is now
> no longer in sync with its upstream counterpart.
> Having not done this in ages, it took me a while to then realise I have to
> do some git stuff to get it back in sync e.g. (and I think I’ve got this
> git fetch upstream (or whatever name you gave it)
> Git checkout master
> Git merge upstream/master
When you did your clone, did you clone the original repository or your
One way to simplify this workflow is:
- you clone always the original repository
- you create a branch and work there
- then you'll push your branch to your fork + fork
That way your branch will be always up to date with the original
repository, and no need to sync (actually the sync is done automatically
when you push to your fork).
Of course this assumes you're doing a new clone every time you work :).
> So I guess my question is - wouldn’t it be helpful if this was a command
> in Iceberg?
It would, there are several places where we could simplify the workflow for
common cases, I agree.
> It seems quite common to fork a project (I think this is still recommended
> for pharo itself isn’t it?)
I'd say its mandatory :). Otherwise you will not be able to push directly
to it because of permission problems (actually all main dev branches are
now blocked so **nobody**, not even admins, push to them directly).
> - and then at some point you need to catchup with that origin again? Or am
> I missing something?
Well, it really depends on the workflow you use. Above I've explained a
workflow that works when you clone every time.
Git is so complex and so low level that you can do lots of different things
First thing is to understand what "catch up with origin" means. In my head
it only means:
- checkout your "to-catchup" branch
- merge the remote "to-catchup" branch and merge it
All the rest is workflow dependent. Even (!!) I would argue that merging is
not, strictly speaking, a correct way to catch up: If you have made changes
into "to-catchup", then merging will not make both branches the same, but
your "to-catchup" branch may have extra commits that you did not want to
And here I'm not saying you should not merge, actually I do it most of the
times because I know that 90% of the times it will be ok, and I do rollback
when I realize I was in the other 10%...
> I guess lots of stuff can go wrong - but if it does - you’d still get the
> same problems on the command line.
Yes, and no. The "lots of stuff can go wrong" can be translated in most of
the cases to "I had a merge conflict". But this is not git, this is
The thing is that with Git, your code is dead in files. With Iceberg, your
code is in the files but it also may be alive in your image too. So
updating code for what you have existing instances, or announcement
subscriptions or other could (and probably will) mess up with the running
So to the typical merge conflict, you may add breaking your running system.
It just seems that for normal situations - it would be handy to run this
> straight in Pharo.
> Thoughts from the git experts?
For these cases, you can do exactly as the command line from Iceberg's UI
- change your branch to your "to-catchup" master
- now you can go to the merge option, and choose to merge your remote
branch into your checked-out branch.
- and push
Of course, this simple workflow works most of the times, but you may find
For those edge cases (typically updating iceberg itself, or trying to
update pharo itself), in the checkout preview you will have the combo with
the checkout strategy: choose the expert mode "do not load the code". This
option will change the branch on git's world, but it will not load the code
in your image.
That is useful if you have living instances for example.
This option will though make a diff between the checked out version and
your image code and show you differences. (think this as a git reset --soft)
To me the fact that we are manipulating live code loaded in the image and
not dead files makes a huge difference, and this makes that extrapolating
git commands to iceberg is not so straight forward :). Also, understanding
that git is stateful/context dependant, and applying an operation means
changing your current state (modify your current branch, change your
current branch) is useful to see the consequences.
In any case, any more concrete suggestions for enhancing this workflow are
welcome. I think that neither Esteban, Pablo, me nor other contributors are
skilled UI designers, and thinking about the best way to present a usecase
to a user is super super hard :).
Guille, from his vacations
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-users