共享Git存储库中的.editorconfig

7
我已经准备好了我想要在多个Git仓库上使用的.editorconfig文件。每个仓库都保存一个Visual Studio解决方案(C#)。我的第一想法是将.editorconfig文件放在自己的仓库中,然后作为子模块包含在所有“解决方案仓库”中。然而问题是:子模块将位于子文件夹中。所以包含的.editorconfig将不会应用于整个项目/解决方案(而只适用于子文件夹及其子项)。似乎我也无法在解决方案配置文件(.sln)中指定路径到我的全局解决方案.editorconfig。
那么,实际上共享单个.editorconfig文件的最佳方法是什么?.editorconfig文件仍需要进行版本控制(因此必须在用户之间共享),即没有本地editorconfig配置。

尝试使用单个共享文件实例的想法来处理这个问题将比拥有一个单一的文件定义更加复杂,该定义定期提交到所有目标存储库。 - StingyJack
这是一种非常个人化的看待事物的方式。对我们来说,这种方法已经被证明非常有帮助。更重要的是,因为我们的共享存储库还包含其他配置文件,如拼写检查字典、eslint配置和多个.ruleset文件。 - Jack Miller
我不会称之为个人行为,有时候复制比分享更容易或更好,特别是在规模上。在我的工作中,我们有大约1.5K个GitHub仓库和大约400名程序员,一些仓库处于休眠状态,但其余的以不同的速度在运动。如果我们更新了一个共享的editorconfig文件,这可能意味着在他们正在进行的工作之上强制执行未计划的工作,而且他们没有办法退出或暂停。如果我们推送并覆盖了一个editorconfig文件的副本,他们只需还原该提交,并在能够处理它时重新应用该文件。 - StingyJack
1个回答

8

我已经找到了一个自己想要的解决方案,使用共享仓库作为子模块: 它是一个符号链接!

例如,如果你的子模块叫做 Global,进入你的解决方案的根目录,并通过以下方式创建指向子文件夹 Global 中真实文件的符号链接:

mklink .editorconfig .\Global\.editorconfig

这个链接可以像任何其他文件一样提交和推送。我正在使用 Gitea 作为服务器,甚至为文件符号显示了一个小箭头叠加。显然它知道这只是一个符号链接。当我在 Windows 机器上克隆此存储库时,符号链接按预期工作。也许它甚至在 *nix 系统上也有效;不过我没有尝试。
这种解决方案的缺点是:VS2017 (15.8.2) 不会立即更新更改。必须关闭并重新打开解决方案。如果你正在使用真正的 .editorconfig 文件,自从15.8 Preview 3以来就能立即检测到更改。 编辑: 我们决定不将符号链接提交到 Git,因为它曾经捣乱过Gitea (可能是一个bug),而且我们有非Windows开发系统。相反,我们有一个“后克隆脚本”,配合项目文件中的条件错误<Error Condition="!Exists('$(SolutionDir).editorconfig')" Text=".editorconfig is missing. Please run $(SolutionDir)_post_clone_script.bat first." />

你认为硬链接会更好吗?例如 mklink /h - Jazz.

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接