On 12 April 2018 at 12:39, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Le 12/04/2018 �� 03:54, Ben Coman a ��crit��:

I was thinking that a smalltalk-implemented merge algorithm would only be used for the Smalltal/Tonel code,
not for any other files.�� And maybe, when a merge is invoked from Iceberg, the callback to the merge-driver
might present conflicts in a GUI to be resolved, but I guess such would require a threaded-VM.

Two things then.

- What happens if the C developer does a merge in a multi-language project containing tonel files?��

- What is the difference with setting and provides a merge driver in Git, which has the ability to work even without libcgit?

I don't quite understand the question.�� By "setting" do you mean in .gitattributes?

The same merge-algorithm could be invoked in two ways.

The first would be "externally" from the shell,

booting an Image to invoke the merge-algorithm

with the files-to-process as arguments. This wouldn't need libgit.

Conflicts could left marked in text files similar to exiting merge,��

or the running Image could present them in a GUI to resolve.

A tool is required either way.

I guess one of the existing options does this already?

But I had imagined a problem(?) in an already running Image, with Iceberg doing a merge through libgit

being able to invoke the merge driver in the already running Image.��

Now you've made me think it through more, I see some holes.

Perhaps its okay to have two Images running��by using the "external" way anyway;

or the merge done purely "internally" before touching git, and just present the resultant "index" to libgit;

and my idea is not needed as a third way.��

Now I find I don't know the depths of the Pharo / libgit interface enough to speculate further here.

cheers -ben