Idea: specify, in EditorConfig files, which git strategy is used by a project

[Atrejoe]

I see many teams having issues formalizing their git strategies (gitflow, trunk-based, no-clue), and even when a strategy would be chosen, the names of the branches need to be manually specified.

It would be cool if strategy could be forma,ized, and branching config could be formalized, allowing git integrations assist branch actions.

Similar to specifying using gitflow config

Which branch should be used for bringing forth production releases?
   - develop
   - main
Branch name for production releases: [master] main

Which branch should be used for integration of the "next release"?
   - develop
   - main
Branch name for "next release" development: [develop] develop

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Bugfix branches? [bugfix/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 

or asissted by a gui, like:

Any ideas on this?

[cxw42]

Could you tell us more about the problem this would solve? This particular repo doesn't change often enough to need a strategy, in my opinion.

Individual editorconfig cores and plugins have their own teams and repos, and I personally wouldn't want to try to dictate workflow to those teams :) .

[Atrejoe]

It's not about formalizing a strategy for this repo, it's about allowing teams to formalize their git strategy in their repo's by specifying it in a .editorconfig file.

For instance, when integrated, git flow could pick up the settings from the .editorconfig file upon checkout, no need for each user to initialize and manually configure branches and prefixes.

[cxw42]

Thanks for the clarification! It makes sense to me that you would want helper tooling to set up git flow for a project. However, I don't think EditorConfig is a good fit for that tooling. As the web site says,

EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.

Git flow, branch naming, and the like are all orthogonal to coding style, so I think would be better served by a dedicated tool.

(I have proposed a "toolconfig" format that would be broader and that might be able to hold such settings. Even there, however, the git flow is not tied to a specific file. Toolconfig would have to be extended to hold edit whole-project settings.)