[Pharo-users] Iceberg working with forks - can it be easier?
guillermopolito at gmail.com
Tue Feb 19 08:08:49 EST 2019
On Tue, Feb 19, 2019 at 2:08 AM Tim Mackinnon <tim at testit.works> wrote:
> Hi Guille - thanks for taking the time to write this up… in the middle
> there I finally spotted the crucial bit “clone the original, push to your
> fork”. I think thats what I’ve been doing wrong - and it leads to all kinds
> of confusion (at least I’m hoping this is what it is).
You've been doing nothing wrong :).
Both are valid things in Git, and to talk about rights and wrongs are fuzzy
at the least there.
> As I have cloned from my Fork (and in my defence - its because we were
> given a repository that collides with the pharo one - exercism/pharo - and
> P7 doesn’t let us clone from that) - so I’ve had to clone from my fork.
Yeh, that's a bug. It should not be difficult to fix.
The thing is, iceberg distinguishes repositories/projects by name.
And names are obtained from the repository/project directory name.
Then, the plugin made to simplify contributions to pharo, detects the
repositories called "pharo" as pharo themselves and do some extra
configuration. What happens in your case is that your repository suffers
from that extra configuration, which is not the right thing to do in your
One Idea that was poking around in my head is to be able to "rename" a
project independently of its location in disk.
We already have a metadata file at the root of the repository. We could add
in that metadata file properties like:
- the project's name (for example you could call it "pharo-exercism" in
there, while keeping the tree structure)
- an extra special property "isPharoRepository : true" that may be defined
only for pharo
- a canonical-repository url which could be used to compare against
pharo's canonical url
Implementing the detection of pharo's repository using any of those
strategies could solve your problem...
What do you think?
> It all seemed to work until I started submitting my PR’s and then they
> seem to include commits going much further back than I think they should
> need Even wen I thought I was being careful and syncing to master - it
> still seems to go back to some of my earliest work.
This looks like a mis-manipulation of branches, and It smells to me that it
is not related to the issue above...
Next time it happens, I'd like, if you can, that you share with me the
that you're trying to make a PR from, to see if we can see the real cause,
and at least build some docs on it ^^.
> Now that we have managed to get the repo renamed - I will try working like
> you have suggested and make sure that it is working like you describe - as
> it shouldn’t be as complicated as this to make clean isolated changes and
> then submit them as a PR. (otherwise Pharo would fall apart).
> One question I do have however - is what is the best procedure if you
> realised when making changes that
> A) you forgot to make changes in a branch (so are working on master)
It depends if your changes have been pushed or not.
1) First thing is to fix your local branch with the expression I told in a
repo branch commit: repo branch commit parent.
2) If you have already pushed, that means that you have to rewrite the
history on the remote side, and that would require a push force (from the
command line so far, unless you would like to implement that in iceberg :P).
> B) you are working in a branch but decide some of your changes should go
> in another branch itself based on master (how to stash?)
There is no stash mechanism in iceberg (so far).
What I do is:
- I checkout the base branch (master in this case) in expert mode => do
not touch my image code, then the image itself will work as a stash
- I now checkout a new branch (that will "fork" from the last commit in my
- I commit only the things I want to commit.
(see that this is not much different from what you would have done from the
terminal except that the checkout strategy will make the stashing
- git stash
- git checkout master
- git checkout -b myBranch
- git stash pop
- git commit
Then you can either
- discard all your extra changes (I'd suggest to have committed them
earlier :)) to be in a clean master+yournewchanges
- or you can go back to your first branch
> These are 2 common scenarios I’ve found when trying to be a good citizen
> for my little project. Do I have to go to the terminal to do this stuff -
> or can I cleanly do these kinds of operations in Pharo (which I think you
> should be able to do, as its so easy to get into either of those states).
I think you can do everything so far except the push force.
Still I'm not happy with what we have (and I'd like to have 48h days) :)
To help in your first scenario:
- It should not be difficult to get the reset on the UI (
- The same with the push force
For the second scenario, what bothers me the most is the special checkout
that may confuse people.
Also, while you're doing it, you may have not committed your code anywhere
=> and that's dangerous, because you may lose it.
So, imagine this: you are in branch A and you have these changes that you
wan to put in branch B.
Instead of doing strange stashing/checkout blah, you create a new branch
temp/AtoB and commit there.
And then you move to B and apply a smart cherry pick operation of your
Martin was visiting the team last week and he had a super nice prototype:
you select what you want to cherry pick from a branch and it automatically
selects all (static) dependencies in the same branch, and proposes you
doing a commit/merge of that.
I don't know how far are we from this, but it would be super nice to do
easy backporting between branches (think pharo8 -> pharo7).
Thanks in advance.
> On 18 Feb 2019, at 08:56, Guillermo Polito <guillermopolito at gmail.com>
> 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 with it.
> 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 introduce...
> 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
> - fetch
> - 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
> edge cases.
> 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
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* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-users