Per-repo config files (and reloading of edited config files)

[stefanhaller]

• PR Description

Support per-repo user config files. For now we only support .git/lazygit.yml; in the future we would also like to support ./.lazygit.yml, but that one will need a trust prompt as it could be versioned, which adds quite a bit of complexity, so we leave that for later.

We do, however, support config files in parent directories (all the way up to the root directory). This makes it possible to add a config file that applies to multiple repos at once. Useful if you want to set different options for all your work repos vs. all your open-source repos, for instance.

In addition, we support re-loading edited config files. This makes it much easier to experiment with config settings, especially the ones that affect the layout or color scheme, because you see the effect immediately without having to restart lazygit.

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 8bcfa361	✅ 68.94%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (8bcfa36)	Report Missing	Report Missing	Report Missing
Head commit (5431c26)	49606	42451	85.58%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#3787)	573	395	68.94%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[stefanhaller]

I added two commits that make keybindings and customCommands hot-reloadable, which gets us a lot closer to the desired end state.

[jesseduffield]

Great work, left some comments.

As for aiming for 100% reloadability, I'm not fussed. Config files should rarely change and when they do change, it's pretty easy to reload lazygit. In situations where it's hard to support auto-reload we could instead prompt the user with the option to restart lazygit (without needing to exit it), such that the change takes effect.

[stefanhaller]

In situations where it's hard to support auto-reload we could instead prompt the user with the option to restart lazygit (without needing to exit it), such that the change takes effect.

I thought about that too, I'll consider this as a last resort for cases where it's too much work to do the real reloading (like for the auto-fetch configs). But it might not be trivial to do either; we'll see.

[stefanhaller]

@jesseduffield I rebased onto master, squashed fixups, and added a few more commits:

• Show a message when changing a config setting that can't be auto-reloaded (2500dfb and 60fd9e7)
• Add information about per-repo config files to Config.md (416ba1a)

I consider this ready now.

[jesseduffield]

@stefanhaller Noted. I'll hopefully get around to reviewing this again soon

[jesseduffield]

This is not guaranteed to work because some fields don't match with their serialized name e.g.:

SuspendOnEdit *bool `yaml:"editInTerminal,omitempty"`

Arguably we should just not have mismatched field names, but the reason this happens is that we think of a better name to use internally, but don't want to break backwards compatibility. What are your thoughts on parsing the tag string to pull out the serialized name?

[stefanhaller]

I was originally planning to read the struct tags, but then was too lazy to figure out how to do that, and hoped I could get away with this simpler version. But you're right, it's not good enough, and actually reading the struct tags is not so hard, see 292e74c.

[jesseduffield]

Great work! This is a great improvement