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 <[email protected]> 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 > >
