Making GDevelop more git-friendly

[arthuro555]

Using GDevelop with git is often a pain, in part because git is not very good at understanding JSON and because GDevelop project files tend to develop conflicts pretty easily. I have a few suggestions to improve the user experience for teams collaborating via git:

[DONE ✅] Multiline strings

While code reviewing through github or fixing conflicts, it is very annoying to deal with multiline text as it is all concatenated into a single line delimited by \n. This is especially inconvenient when dealing with JS code. Since GDevelop's SerializerElement know as which type a value should be parsed, the value doesn't have to be stored as JSON text, instead we could output multiline text as an array of strings:

"inclineCode": "const hello = \"\";\n\nif(\n    hello === \"world\"\n) {\n    console.log(\n        1\n    );\n}\n\n"

Would become:

"inlineCode": [
  "const hello = \"\";",
  "",
  "if(",
  "    hello === \"world\"",
  ") {",
  "    console.log(",
  "        1",
  "    );",
  "}",
  ""
]

Which allow to fix conflicts on a line-by-line basis way more easily, and would also make reading JS code of extensions while reviewing them more easy.

Allow to store user specific UI settings like the scene zoom level in a gitignore-able file

See #1983

Allow to use defaults for folding

Storing and thereby committing what events are folded or not generates conflicts everywhere all the time. While it is understandable to want the events to be just as they were when one left them, I think it would be nice to provide an option to not store them at all and instead use a default fold. Personally, I am fond of having all events kinds unfolded except the Group events, and would love a feature to have that as a default.

Avoid changes in property order

Behavior contents are using a SerializerElement as a data structure. That works, but unlike std::map it doesn't sort the keys by value but by insertion order instead. That means that the values can sometimes be moved around in the JSON, even if the key and value have not changed, generating unnecessary differences in the JSON file that make it more likely to generate conflicts for nothing.

[Bouh]

Using GDevelop with git is often a pain, in part because git is not very good at understanding JSON.

Yes, it's difficult to read an edit made on a project or in an extension due to how are stored the events, especially for a javascript code block inside a project.

[4ian]

• Agree on multiline strings
• Agree on storing UI settings in a separate file (or even in preferences, indexed by the project UUID)
• Agree on folding (could also be stored separately)
• Agree on properties order in serialization.

All of this, especially the first one, could help a lot.

[Alios5]

yes I was asking not long ago if it will be possible in case we choose that our project is put in several files (For teamwork) would it be possible to manage the resources of each scene earlier than in game. JSON, because even if we work on different scenes, it creates conflicts when everyone adds objects to the game because the resources are managed by game.JSON. This forces us to sacrifice some resources at the expense of others and to reload them all which is really tedious)

[arthuro555]

Idea: we should add a final element to arrays, which could just be a string like "// end of resources list or whatever.

That's because the last element in a JSON list has no ,, so when we add an element at the end of the list, on two separate branches, it thinks you're rewriting the same existing line where a , is added. Adding an extra element at the end of the array would allow to always have a , and thus to be always treated as pure insertions by git instead of conflicting changes

[arthuro555]

Well, git would still probably detect a conflict in this scenario, but it would be easier to resolve as you don't have to think about the ,