外部支持工具需要针对不同仓库分别进行配置

[ccpwcn]

写在前面

我用了很多Git的可视化工具，包括大名鼎鼎的SourceTree，但是不知道为什么，它们在我的电脑上很卡慢（虽然我的电脑配置并不低），而SourceGit运行的非常好，我很喜欢。

现象

一个前端项目，nodejs的。提交代码的时候，提示错误：.git/hooks/pre-commit中的node command not found。 简而言之，提交代码之前，要调用node命令进行代码检查（比如ESLint）等一系列动作（许多软件项目都支持这样的操作），但是node命令找不到。

分析

之所以出现这种node命令不存在的问题，是因为我的电脑上有多个软件工程项目，有多个nodejs，A项目依赖于node 14，B项目依赖于node16，C项目依赖于node 18，类似于这样，所以我没有在系统的PATH环境变量中配置全局的node，都是在各项目中具体配置的。 那么，SourceGit在提交代码的时候，就不能去调用全局的node.exe做代码检查或者执行git的hooks，很明显，这样做要么会报错，要么结果是不可预测的，得为各仓库分别配置和应用相应的功能。

思考

node项目如此，Java项目亦是如此，比如A项目是JDK8的，B项目是JDK11的，Python似乎也不例外，A项目是Python2的，B项目是Python3的，等等。

总而言之，不同版本的兼容性总是存在。有的版本兼容性似乎没那么差，比如Golang 1.11和1.16，但有的版本兼容性差异非常大，比如JDK8的项目如果用JDK7 的hooks去检查，那么lambda表达式是非法的，Python2和3类似，Golang 1.18中的泛型，对于1.17来说也是错误语法，gofmt通不过，那么git的hooks就要出错了。

讨论

那么。。。怎么解决这个问题呢？ 似乎灵活和优雅的方式是：为每位仓库创建一份配置，可以分别指定外部应用程序工具，调用指定的node.exe、java.exe、python.exe等等（我们可以叫它开发者工具包，或者Interceptor，解释器等等），才能避免这个问题。

[love-linger]

换一个思路，如果在仓库配置页，配置本仓库专有的附加PATH路径列表（会在启动git命令时，追加到系统PATH路径列表之后），你看是否会解决您的问题呢？

[love-linger]

因为，配置一些外部工具，如node.exe等脚本解释器，SourceGit并不知道仓库在何时会使用这些工具。比如，上文提到的hooks，这些是由git程序负责执行，而非SourceGit本身。

[ccpwcn]

换一个思路，如果在仓库配置页，配置本仓库专有的附加PATH路径列表（会在启动git命令时，追加到系统PATH路径列表之后），你看是否会解决您的问题呢？

这是个好办法，但是应该支持为每个仓库配置多个环境变量（PATH当然是其实之一），因为某些仓库可能有PATH就够了，比如Golang，但是某些仓库，可能还需要其他环境变量，比如提交前test的时候要区分环境，比如Java除了PATH中有java.exe，还必须有CLASSPATH等等。

[love-linger]

刚才仔细想了一下，可能这样也不太合适。建议还是在hooks中直接使用绝对路径

[ccpwcn]

刚才仔细想了一下，可能这样也不太合适。建议还是在hooks中直接使用绝对路径

刚手动配一下git hooks，可以成功了。算了，这确实不是SourceGit的事情。关闭吧。