On 12 April 2018 at 12:39, Thierry Goubier <thierry.goub...@gmail.com>
> 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
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
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.