Difficulty to use Iceberg

> On 22 Sep 2019, at 09:15, Jan Vrany <[hidden email]> 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
>
>

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

> Jan Vrany wrote
>> What is the correct workflow to end up with:
>> --- A --- B --- C --- D --- E
>
> Not in front of an image, but IIU/RC if you’re seeing “detached”, click
> repair, then the option where you use the repository version (which I think
> I the last one), then - if the outside changes didn’t effect the Smalltalk
> code - from the drop down choose “don’t check anything out” which is
> confusing but means that it won’t try to reload any packages in Pharo.  The
> result of those steps should be that Pharo recognizes the latest commit. Let
> me know whether it works and I’ll be more exact when I get in front of a
> computer