On 2024-01-07 08:03, Stefan Haller wrote:
Our git client (lazygit) has a need to store per-repo config files that
override the global one, much like git itself. The easiest way to do
that is to store those in a .git/lazygit.cfg file, and I'm wondering if
there's any reason why this is a bad idea?
In a worktree (created by "git worktree"), .git is a file not a directory.
Worktrees are designed to each have their own .git directory, which you
can find with "git rev-parse --git-dir". If you just want a single,
repo-wide config file, not a per-worktree config, you probably want to
instead use "git rev-parse --git-common-dir" to find the "main" repo's
.git directory.
The problem of finding a worktree's .git directory goes away if you use
Git's own config system, though.
Another alternative would be to store the config values in .git/config
(that's the path taken by git gui, for example), but since our config
file format is yaml, this would require translation. It would be trivial
for scalar values such as int or string, but I'm not sure how well this
would work for more complex settings like lists of objects.
Any thoughts?
YAML is a horrid little format (hey, you asked for "thoughts"!), and
IIRC Git's config file format only supports multi-line values with
\-escaping and similar patterns, making it nearly impossible to directly
embed YAML in Git's config file. Ideally, if you do use Git's own
config then you really should just drop YAML altogether.
But you have a couple of options without going so far as translating all
the YAML constructs you use into git-config ones. For example, you
could replace all the newlines in a YAML blob with \n to make a
single-line value that you could store in Git's config file. That
complicates hand-editing the YAML though, if that's a use case you care
about.
But even if you replace all the newlines with \n, in my experience there
are always corner-case clashes when mixing file syntaxes (e.g. quoted
strings are often problematic, and maybe some of your YAML values are
themselves multi-line). If you want to use Git's own config file but
stick with YAML, and you really don't care about directly editing the
YAML, I suggest you encode the entire YAML blob in a robust single-line
format, like base64, and store/retrieve that using "git config".
You could still support hand-editing the YAML with a command like
"lazygit editconfig", too.
M.