[llvm] [DRAFT][clang-format] helper script for resolving downstream reformat… (PR #80462)

[Bruno De Fraine via llvm-commits]

https://github.com/brunodf-snps commented:

> It is very close to the libcxx script, but implemented for explicitly running via git mergetool rather than automatically running on every merge. The idea is that if you get a conflict after merging a reformat, you run git mergetool and it will fix the conflicts for you. It takes an extra manual step, but doesn’t impose a cost on every merge forever.

Back for the libcxx script, I [also remarked](https://github.com/llvm/llvm-project/pull/73712#issuecomment-1836356653) that I would prefer to run this kind of script in a manual step, but I did not know how.

Configuring the script as a mergetool seems like a great idea, but when testing this I notice some problems. When the conflicts are only due to formatting, I think it works as intended. But when there are other (actual) conflicts too, then these conflicts are silently marked as resolved (although the conflict markers remain in the file). As a user, I don't see there are conflicts (left) and it is very easy to make the mistake to check in the conflict markers.

I also tried a tweaked mergetool configuration, where I add the [trustExitCode](https://git-scm.com/docs/git-mergetool#Documentation/git-mergetool.txt-mergetoollttoolgttrustExitCode) setting. Then git-mergetool detects from the exit code of git-merge-file that the merge is not complete, but it seems to restore everything in its original state: I'm left to resolve all the conflicts in the file, both those from formatting, and the actual one(s). Essentially, the script is no help then.

I think that git-mergetool expects that the tool (e.g. vimdiff) through user interaction will resolve the conflict completely (or abort). This works differently in the configuration as a merge driver: this can resolve the conflicts due to reformatting, and leave you with the other ones.

https://github.com/llvm/llvm-project/pull/80462