Martin von Zweigbergk <martinvonz@xxxxxxxxx> writes: > I've searched the list and not found anything about this topic, but I > figured I'd ask to be sure. The question is not specific to Git, but > this seems like a forum where it might have been brought up. > > You could imagine having a merge tool that was specialized for some > purpose and only able to resolve a particular kind of conflict. An > example would be a tool that resolves conflicts in `#include` lines or > `import` lines. It could be useful to have such tools run as part of a > chain of merge tools, where the final merge tool is what users > normally have configured (such as `meld`, or the internal "attempt > merge, or leave conflict markers" tool). > > Has this problem come up before? I do not recall seeing such a topic, but I am not sure how practical your idea is to implement from the Git side. As a zeroth order approximation, instead of such a half-auto-merge tool, while resolving a conflicted merge with two conflicted hunks in a file, if you hand edit one conflicted hunk and then run "git mergetool", is your "half resolution by hand" seen by the mergetool backend correctly? I tried to follow from git-mergetool.sh::main() what happens. Each path is given to merge_file() helper function, and three temporary files, $BASE, $LOCAL, and $REMOTE, are prepared from the blob object registered in the index at stages #1, #2 and #3. A mergetool backend, e.g. mergetools/meld, looks at these three files in its merge_cmd() function. Notice that the contents in the working tree file after a conflicted auto-merge does not even get looked at by the mergetool backend in the above picture? I am not sure if replacing the contents of LOCAL with your half-resolved contents would give us the behaviour you want. If it were the case, perhaps vanilla "git mergetools" would have fed the current file in the working tree, which was half resolved by "git merge" with conflict markers, as LOCAL to the mergetool backend even before we started discussing this topic, so I am not that optimistic. I assume that your idea is that various small "I know how to resolve only this kind of conflicts" tools can plug into a larger merge helper framework to improve end-user experience, and I find the idea intriguing. I would be surprised if such an idea has never been discussed by folks in projects that develop and maintain merge helpers, like meld and kompare. But I am not convinced if it is a good idea to do that on our side, before we spawn these mergetool backends.
