2018-04-12 7:51 GMT+02:00 Ben Coman <b...@openinworld.com>: > > > 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?
Yes. > 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? Yes. The GitFileTree-MergeDriver works like that. It is a headless image, now buildt out of the Pharo6 minimal image, and it is called by git for specific file types. What is missing is the GUI part, like a git merge-tool like meld can do. > 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; Yes: in that case the merge driver is called in another process anyway. Also, you want to reduce the overhead (make the pharo-based merge driver as fast as possible to start, because git will start it for each file to merge). The nice thing with that setup is that the common ancestor search is done by git. > or the merge done purely "internally" before touching git, and just present > the resultant "index" to libgit; That one has the issue of having to deal with non-smalltalk files (i.e. write a generic merge tool). If you restrict yourself to smalltalk merges, then that can be fine (i.e. you merge with Monticello, and the resulting package is stored as a merge in the git store). But you reverse who is the master... in the later, smalltalk is the master, and git store smalltalk results; in the merge driver, git is the master, and smalltalk does what git requires. But someone can still come from the outside of the repo and do a merge on the command line; which is also fine. > 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. Yes, it seems that there are multiple ways to interface with it. Thierry > cheers -ben
