librelist archives

« back to archive

Configuration API preview

Configuration API preview

From:
Carlos Martín Nieto
Date:
2011-03-29 @ 16:22
Hello,

 I'm working on the configuration parsing and now that it more-or-less
works, I need to decide on an API. I've pushed this to my config branch
[0] on GitHub, and you can see the doxygen-generated documentation at
[1].

 Right now, I have
    git_config_set
    git_config_set_int
    git_config_set_bool
    git_config_set_string
    git_config_get
    git_config_get_int
    git_config_get_bool
    get_config_get_string
as getters/setters. _int and _bool work as wrappers around the more
general functions.

 There is also the
    git_config_foreach
function, which calls a function with , which I use right now to check
that the parsing code works but will also be useful later (at least for
`git config -l`).

 There are obviously git_config_open and git_config_free. The git_cvar
access functions are still missing, but I should push them out later
today.

 Other than the git_cvar accessors, I don't think I'm missing anything
needed for a git-config implementation (API-wise, the parsing is still a
WIP, but that shouldn't take long either).

 Comments?

   cmn

[0] 
https://github.com/carlosmn/libgit2/tree/confighttp://carlosmn.github.com/libgit2/group__git__config.html
[1] http://carlosmn.github.com/libgit2/group__git__config.html

Re: [libgit2] Configuration API preview

From:
Scott Chacon
Date:
2011-03-29 @ 16:42
Hey,

On Tue, Mar 29, 2011 at 9:22 AM, Carlos Martín Nieto <cmn@elego.de> wrote:
>
>  Other than the git_cvar accessors, I don't think I'm missing anything
> needed for a git-config implementation (API-wise, the parsing is still a
> WIP, but that shouldn't take long either).
>
>  Comments?
>

It would be nice if there was something that helped generate the path
needed for the git_config_open command - maybe something from the
repository object that would return one of 'local', 'global' or
'system' config objects without you having to specify the path.  Also,
it would be nice to have some super-config object that aggregated all
three of them for reading - I want to be able to say 'what is the
value of user.name for this repo' and have it cascade the three config
files to find the applicable one.  I don't want to have to manually
open three separate config objects and check for the value in each
until I find it.  It's pretty rare that anyone cares to just look in a
single config file.

Scott

Re: [libgit2] Configuration API preview

From:
Carlos Martín Nieto
Date:
2011-03-29 @ 17:42
(librelist apparently ate my reply to the list)

On mar, 2011-03-29 at 09:42 -0700, Scott Chacon wrote:
> Hey,
> 
> On Tue, Mar 29, 2011 at 9:22 AM, Carlos Martín Nieto <cmn@elego.de> wrote:
> >
> >  Other than the git_cvar accessors, I don't think I'm missing anything
> > needed for a git-config implementation (API-wise, the parsing is still a
> > WIP, but that shouldn't take long either).
> >
> >  Comments?
> >
> 
> It would be nice if there was something that helped generate the path
> needed for the git_config_open command - maybe something from the
> repository object that would return one of 'local', 'global' or
> 'system' config objects without you having to specify the path.  Also,

 I think git_repository_open should take care of reading the
configuration files. "Normal" users would go and ask the repo for the
config (since everything needs the repo pointer or something containing
it). This should be added to the repository API, though.

 git-config still needs to open it itself because it deals with the
configuration more directly and may not even be in a git repo at all
when used with --global.

> it would be nice to have some super-config object that aggregated all
> three of them for reading - I want to be able to say 'what is the
> value of user.name for this repo' and have it cascade the three config
> files to find the applicable one.  I don't want to have to manually
> open three separate config objects and check for the value in each
> until I find it.  It's pretty rare that anyone cares to just look in a
> single config file.

 The super-config object is a good idea. This could be what the
repository gives to its users. If git-remotes uses some special hooks
(as it only really ever needs to write to the local config), it could be
marked read-only for safety.

   cmn