On Mon, Feb 4, 2019 at 4:17 PM Christian Couder <christian.couder@xxxxxxxxx> 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
