Split `project.godot` into multiple files to reduce merge conflicts

[KoB-Kirito]

Describe the project you are working on

This applies to all projects on which you work together with others. I see this problem every game jam.

Describe the problem or limitation you are having in your project

Godot saves far too much in the godot.project file. Even if everyone in the team is working on other areas, this central file often leads to merge conflicts.

One person names a layer, another adds a node to a group, someone else needs a different key for an input, someone is working on a shader and needs a global variable, the audio guy sets a default bus layout: merge conflict.

godot.project has become a storage location for all code areas. I don't know if it's just the bad example, or if Godot favors this approach, but most addons also store their settings in project.godot, which leads to more problems. We particularly noticed this during the last jam with Dialogic, an addon for creating visual novels. The people who worked on the story were not very familiar with git and Dialogic saves every new timeline in project.godot. We had merge conflicts all the time.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

You could look at the individual areas that are writing in godot.project and consider whether this is really necessary, but that would probably be a lot of work.

I would suggest splitting the file. It is already divided into sections. The simplest thing would be to put each section in a separate file, possibly in a config folder.

Those files could also follow the convention of .cfg files in other projects.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Strip every section out of project.godot and put it in a separate file in a .config folder.

project.godot would just keep the version, maybe a path to the config folder. If really needed some essentials like [application].

In the .config folder the other sections would live:

audio.cfg
autoload.cfg
display.cfg
etc...

If this enhancement will not be used often, can it be worked around with a few lines of script?

I don't see how. You could add nodes to groups in _ready for example, but you lose the convenience of the UI and you can't find solutions for everything.

Is there a reason why this should be core and not an add-on in the asset library?

Fetching these is done by the Godot core. Also I don't see any downsides. But it could be an optional setting of course.

[Calinou]

I'm not sure splitting each section of the project settings into its own file will reduce merge conflicts, since Git merge conflicts are paragraph-based, not file-based. If two changes are separated by at least one blank line, Git will be able to deal with it in a clean way.

Dialogic saves every new timeline in project.godot.

Couldn't Dialogic be modified to save its timelines to a separate file?

Strip every section out of project.godot and put it in a separate file in a .config folder.

If the folder name starts with ., people might think they have to add it to their .gitignore, while these files should be committed to version control to match the current behavior.

[KoB-Kirito]

I'm not sure splitting each section of the project settings into its own file will reduce merge conflicts, since Git merge conflicts are paragraph-based, not file-based. If two changes are separated by at least one blank line, Git will be able to deal with it in a clean way.

Somebody else also told me that too. I guess we are too dumb then or it depends on the GUI you use. Most beginners use Github Desktop, and we had people that couldn't pull because of the godot.project several times ¯\(◕◕)_/¯

Couldn't Dialogic be modified to save its timelines to a separate file?

Yeah, I proposed that. But while doing so I figured that this is a problem broad enough to effect Godot in general. I think there might be a better way.

If the folder name starts with ., people might think they have to add it to their .gitignore, while these files should be committed to version control to match the current behavior.

It shouldn't show up in the file drawer though and a lot of projects already have a folder called config.

[dalexeev]

There is override.cfg:

Any project setting can be overridden by creating a file named override.cfg in the project's root directory. This can also be used in exported projects by placing this file in the same directory as the project binary. Overriding will still take the base project settings' feature tags in account. Therefore, make sure to also override the setting with the desired feature tags if you want them to override base project settings on all platforms and configurations.

[KoB-Kirito]

Neat. That is per setting? Can you configure the editor to write there then though? Doesn't really help with the proposed problem.

[Calinou]

Can you configure the editor to write there then though?

The editor itself will not write anything there by default, but an editor plugin can write to it using the ConfigFile class. It just needs to use ConfigFile on override.cfg instead of using the ProjectSettings singleton.

[KoB-Kirito]

I see, will suggest that. Thank you.