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

Reply via email to