Re: [GSoC PATCH v2] userdiff: add builtin driver for gitconfig syntax

From: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com>
Date: Mar 25, 2025, 18:34 UTC
Message-ID: <FE085EEC-0BCC-43D9-9F17-1A7060DC4D6E@gmail.com>
In-Reply-To: <d4c0c9a4-0402-4456-9fa0-3102b5bcc3dc@kdbg.org>

> Can we please have a more recent reference? The difference of config.txt
> here and config.adoc above is very surprising.

Hmmmm... My idea was to reference the last change in the paragraphs of the documentation, but I'll change to the last change of this file.

> The file format of .git/config files isn't specific to .git/config; it's
> called "ini-file" and is already very old. Wouldn't it make sense to
> generalize the format? It would be just a matter of choosing a different
> name; the regular expressions would not have to change.

Indeed. This is was written having the gitconfig in mind, but perhaps I could use a different approach and make a little more flexible for other INI flavors and perhaps even TOML

> This could test two sub-sections in a row and ensure that the later one
> is chosen.

Nice! I'll do that.

> What happens if there is an *indented* header after the "RIGHT" one?
> Should it be chosen or not? Can this happen in a valid file?

I just tested here, it is valid file. I'll take indentation into acoount in v3.

Show 5 quoted lines

> The regular expression can assume that the syntax of the processed file
> is correct. For example,
> 
>   [!not a section!]
> cannot be a section header and will not occur in a valid file. Or can it?

Following the gitconfig syntax specification it can't be in a valid file, and this regex won't match it.

> Therefore, it would be sufficient to just take everything after the '['
> at the beginning of the line without further inspection.

I can't see any harm in just dropping the section name matching and using a generic /\[.+\]/. It may be also useful for more generic INI files that you mentioned before.

> Furthermore, a valid file can look like this:
> 
> [section] key = value
>  another_key = more values

To be honest, I didn't know that it could was a valid file. I'll include that in a v3.

Thanks for your extensive review!