Guillermo has found a bug in Iceberg that is slotted to be fixed at the next update, and has provided a temporary workaround.
��
I have to final notes about the "merge" method:

1. After the merge, you must explore the packages and reload any that you've been working on in order to have classes of the correct versions. This was OK for me but might be a problem for people who work on classes all over the place;

2. When committing new changes to your locally merged branch, you will have to sift through every single package and class in the Commit window, since it sees now that just about everything has changed. Again, it helps to know what exactly you've been working on ahead of time. Perhaps a filter on package names (like in Calypso panes) would be a good start?

On Wed, Aug 1, 2018 at 9:25 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:


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



On Wed, Aug 1, 2018 at 2:02 PM Eric Gade <eric.gade@gmail.com> wrote:
Every week some tenths of pull requests are integrated in Pharo, so loading the Pharo7 image of today will give you an image compleeetely different from the one you worked with one week ago.

This is something I'm used to from the non-Pharo Git world. Normally I would do what it called "rebasing," which essentially replays any commits on my branch atop the HEAD of the current master branch. In cases where you know that the things you're working on are unlikely to have changed in the meantime, this tends to work most of the time.

Well we do not support rebase in iceberg yet. In part because we would like to keep the UI as simple as possible (because lots of people do not really know git) and in part because I personally believe rebase as an evil feature that people tend to overuse. (That does not mean that rebase is bad in itself, I actually use it myself from time to time, but I'm strongly against rewriting public commits/history).

I support this ^��

:)

��
����
For your particular use case (have a new image and want to keep working on an old pharo branch), I'd suggest that instead of doing��"Discard local changes and checkout existing branch"��you do

I'll give this a shot in a little bit and let you know if it works.

Cool!��


You have the popup with the "Ignore" and "Debug" options? Could you click on "Debug" and share your stack trace?

No. This is not the normal error popup. It's more like a little dialog that only has text and an OK button. However, I was able to go into the repository via Iceberg and attempt to checkout the branch from origin directly. That did give me a normal error and I do have a fuel dump of the stack. Unfortunately it is too big to attach to emails to this list.��

If you want, send me a dropbox link or something like that personally...
��

I will send a follow up message with the attachment, but it will need mod approval.��

On Wed, Aug 1, 2018 at 7:52 AM, Guillermo Polito��<guillermopolito@gmail.com>��wrote:
Ah, just in case I add to what I say: this particular tricky scenario is specific for Pharo and contributing to Pharo.��

Any third party project/library will not have the constraints described in my previous email.

On Wed, Aug 1, 2018 at 1:48 PM Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi!

On Wed, Aug 1, 2018 at 1:30 PM Eric Gade <eric.gade@gmail.com> wrote:
I have already mentioned some of this on Discord so forgive me for being redundant if you've seen it.

I'm having problems loading into the latest P7 images from Launcher a working branch of Pharo that I have forked. I perform the following steps:

I'll try to reproduce it, but meanwhile.
��
1. "Repair" the missing local repository for Pharo and load from my forked version on Github
2. Now in the "detached working copy" state, I repair again
3. This time I select "Discard local changes and checkout existing branch". I select my working branch from the remotes

I have a remark on this step, that should be known and understood by people contributing Pharo.��
- When you download an image, that image knows from which commit it was built. This is done on purpose so then you can continue working from exactly that commit (less merge problems, do not need to update your live image...).
- Every week some tenths of pull requests are integrated in Pharo, so loading the Pharo7 image of today will give you an image compleeetely different from the one you worked with one week ago.

What this means, is that if you checkout an old branch, Iceberg will try to "downgrade" all your packages to your branch's version, and that may not always work, because while updating pharo packages you may break running code and running instances (take into account you have several processes running). This is the same problem of the old "Software update" option in Pharo that was deprecated and removed some time ago already. And this is why in general we do not recommend nowadays to update a pharo image through iceberg, because you cause a kind of self brain-surgery scenario.

This is why also we DO recommend, when you start with a new image to "create a new branch from the image commit". Because this option makes you work on a branch that is 100% in sync with your Pharo image and it will just simplify your life :).

For your particular use case (have a new image and want to keep working on an old pharo branch), I'd suggest that instead of doing��"Discard local changes and checkout existing branch"��you do
��- load your fork
��- create *new* branch from image
��- merge your old branch into this new one

That will be by far less disruptive.
��
4. It will attempt to load, but eventually a popup appears (not a normal error) that simply says "origin: Error" and "Assertion failed".

You have the popup with the "Ignore" and "Debug" options? Could you click on "Debug" and share your stack trace?
��

I'm not sure what's going on, since this procedure seemed to work a week or so ago if I remember correctly. As of a couple of days ago I can no longer load (ie work on) my working branch.

Well, this is for sure related to what I described above, using a new image with an old branch....
��

I figure I'm doing something wrong, but need to know what.

Maybe not, and it's just a matter of a complex scenario��+ an unexpected case in iceberg��(thus the assertion).

Keep us updated to see if we can help you,
Guille


--��
������
Guille Polito
Research Engineer


Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research -��http://www.cnrs.fr

Phone:��+33 06 52 70 66 13



--��
Eric


--��
������
Guille Polito
Research Engineer


Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research -��http://www.cnrs.fr

Phone:��+33 06 52 70 66 13




--
Eric