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