Hi Christian, On Sat, 19 Sep 2020, Christian Couder wrote: > On Wed, Sep 16, 2020 at 10:27 PM Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > On Wed, 16 Sep 2020, Christian Couder wrote: > > > > To summarize more, it seems to me that only the following scripts > > > could be worth converting: > > > > > > git-difftool--helper.sh > > > git-mergetool--lib.sh > > > git-mergetool.sh > > > > > > I wonder if they are really worth converting though, as they should > > > probably all be converted together and we would likely also need to > > > convert the scripts in mergetools/ at the same time. And then there > > > should be a way to still easily configure things for users. So perhaps > > > a better way to approach this would be first to convert the scripts in > > > mergetools/ into config files. > > > > The biggest problem is that they're all entangled. > > `git-difftool--helper.sh` sources `git-mergetool--lib.sh` and uses quite a > > bit of its machinery. > > Yeah, I agree this is an issue. > > > As to converting the scripts to config files, I'd rather have them > > hard-coded in the source code. > > I am not sure what are the pros and cons of hardcoding vs config files > in this case. The thing is: `make install` does not install a Git config. That's why I want the defaults hard-coded. Of course, it should be possible to override those hard-coded defaults via the config. That should go without saying. Ciao, Dscho > My opinion is that config files would make it easier for people to > contribute what's needed for new tools, while hardcoding might make it > more easily extensible for us and might reduce backward compatibility > issues. > > > I would then probably try to implement the bare minimum for the > > `difftool--helper` command to work (re-implementing in C only the parts of > > `mergetool--lib` that are necessary), and only in a next patch series work > > on `mergetool`. > > Thanks for your opinion on this. For now I think it needs to be > discussed more before we could suggest it as a project. > > Best, > Christian. >