7

I have prepared my .editorconfig file which I want to use on multiple Git repositories. Each repository holds a Visual Studio solution (C#). My first thought was to put the .editorconfig file in its own repository and then include it in all "solution repositories" as submodule. The problem however: The submodule will be in a subfolder. The contained .editorconfig will thus not be applied to the whole project/solution (but only to the subfolder and its children). It seems to me that I cannot specify a path to my solution-wide .editorconfig in the solution configuration file (.sln), either.

What is the best approach to actually share a single .editorconfig file between multiple Git repositories? The .editorconfig file still needs to be version controlled (and thus shared between users), ie. no local editorconfig configuration.

Jack Miller
  • 6,843
  • 3
  • 48
  • 66
  • Trying to work with this with the idea of a single shared file instance is going to be more complicated than having a single file definition that is periodically committed to all target repos. – StingyJack Mar 11 '21 at 16:30
  • That is a very personal way of looking at things. For us this approach has proven very helpful. Even more so because our shared repository also contains other configuration files, like spellcheck dictionary, eslint configuration and multiple .ruleset files. – Jack Miller Mar 13 '21 at 12:52
  • I wouldnt call it personal, sometimes its easier or better to replicate than it is to share, especially at scale. At my work we have like 1.5K GH repos and about 400 programmers, some repos are dormant but the rest are are moving at different paces. If we updated a single shared editorconfig, it could mean forcing unplanned work on top of something they are in the middle of without a way for them to back out or hold off. If we push-overwrote a copy of editorconfig they could just revert that commit and have the file reapplied when they were able to deal with it.. – StingyJack Mar 13 '21 at 14:57

1 Answers1

8

I found a solution myself using a shared repository as submodule as I wanted: It's a symbolic link!

For example, if your submodule is called Global, go into the root of your solution and create a symbolic link to the real file in subfolder Global via:

mklink .editorconfig .\Global\.editorconfig

This link can be committed and pushed like any other file. Gitea (which I am using as server) even shows a small arrow as overlay for the file symbol. Apparantly it knows that it is just a symbolic link. When I clone this repository on a Windows machine, the symbolic link works as expected. Maybe it even works on *nix systems; I did not try though.

I draw back of this solution: VS2017 (15.8.2) does not pick up changes immediately. One has to close and re-open the solution. If you are using a real .editorconfig file changes are detected immediately since 15.8 Preview 3.

Edit: We decided not to commit the symbolic link to Git because it once screwed up Gitea (might have been a bug) and because we have non-Windows development systems. Instead we have a 'post clone script' in combination with a conditional error in our project files <Error Condition="!Exists('$(SolutionDir).editorconfig')" Text=".editorconfig is missing. Please run $(SolutionDir)_post_clone_script.bat first." />.

Jack Miller
  • 6,843
  • 3
  • 48
  • 66