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 <[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 >> >>
