Re: GSoC 2019: Git's application submitted

[Duy Nguyen <pclouds@gmail.com>]

On Mon, Feb 4, 2019 at 4:17 PM Christian Couder
<christian.couder@gmail.com> wrote:
>
> Hi everyone,
>
> There are now ideas, micro-projects and organization application pages
> for GSoC 2019 on https://git.github.io/
>
> It would be nice to have a few more project ideas.
> https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible
> projects:
>
> - Unify ref-filter formats with other --pretty formats (which is new)
> - git log --oneline improvements
>
> as I didn't feel that the others were still relevant, though I might be wrong.
>
> As Olga and Thomas told me at the Git Merge that they could be ok to
> co-mentor with me, they are listed as possible mentors for both of
> these projects.
>
> Anyway feel free to comment and suggest improvements on those pages,
> especially the micro-projects and ideas one. Pull requests on
> https://github.com/git/git.github.io/ are very much appreciated.

I'm not opening a pull request because I'm not sure if it's worthy of
GSoC (probably 2020, not 2019) but anyway the get_config_* discussion
elsewhere reminds me of this.

Currently we have two ways of parsing config files, by a callback that
gives you everything and you do whatever you want, and with configset
where you can just call "get me this config", "get me that one". The
idea is moving most callback-based sites to get_config_ one.
Preferably in a declarative style, like 'struct option[]'.

This should reduce some amount of code because all the "if (!strcmp..)
var = git_confg..." is handled by a common code. It's easier to read
too. And it may open up an opportunity to suggest misspelled config
name (a bit far fetched) and list relevant configs of any command,
perhaps with a short description of each config variable too. The
configset way should be a bit faster too, but I don't think we care
about performance at all here.

To handle three-level config like remote.*.url, we can still do it the
declarative way by declaring the pattern "remote.*" instead of a fixed
variable name which we can't know in advance. There will still be a
callback to handle remote.* vars correctly, but the callback should be
much smaller and easier to manage, I hope.
-- 
Duy