On 12 April 2018 at 12:39, Thierry Goubier <[email protected]> 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
