Hi Tim, thanks! Yes, there are other ways to get around this, but all i tried are major PITAs. Was wondering there must be a better way... Thanks anyway! Jan
Hi Jan - if Iâve understood you correctly, I think this is the same issue you would get with a readme.md file in the root of your project, as iceberg only deals with its repository tree and nothing else (which has been queried in the past - but itâs a design decision for now, weâve been told).
To workaround this, checkout your project into a separate directory for the C part, and pull push independently from pull push in Pharo part (eg, just pretend you are different users collaborating on the same project). It works, but remember to do the pull - to catchup when you have done something in the other world.
Tim
Sent from my iPhone
On 22 Sep 2019, at 09:15, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Hi,
I'm experiencing difficulties (code loss, even) when trying to commit code using Iceberg.
I have a project with consist of some Pharo code and some C++ code. Both parts kind of depend on each other.
Imagine I start from commit A
--- A
and build and open Pharo image. Then I do some work in Pharo and commit, leaving me at B:
--- A --- B
Now I need to make some changes to the C++ code, say C & D:
--- A --- B --- C --- D
And work little more on C++ but do not commit (therefore I have modified C++ files and/or staged changes). Now imagine I need to do more changes in Pharo image and commit (should be commit E)
Now there's the problem. Pharo image thinks it is still at commit B and starts complaining about image being out if sync.
What is the correct workflow to end up with:
--- A --- B --- C --- D --- E
!!! AND !!! with my local modifications to C++ code preserved in working copy? I'd be nice to preserve staged changes too, but I'd be OK to unstage all changes if necessary.
Any suggestions?
Best, Jan