src/config.h


Log

Author Commit Date CI Message
Brodie Rao 01ad7b3a 2011-09-06T15:48:45 *: correct and codify various file permissions The following files now have 0444 permissions: - loose objects - pack indexes - pack files - packs downloaded by fetch - packs downloaded by the HTTP transport And the following files now have 0666 permissions: - config files - repository indexes - reflogs - refs This brings libgit2 more in line with Git. Note that git_filebuf_commit() and git_filebuf_commit_at() have both gained a new mode parameter. The latter change fixes an important issue where filebufs created with GIT_FILEBUF_TEMPORARY received 0600 permissions (due to mkstemp(3) usage). Now we chmod() the file before renaming it into place. Tests have been added to confirm that new commit, tag, and tree objects are created with the right permissions. I don't have access to Windows, so for now I've guarded the tests with "#ifndef GIT_WIN32".
Vicent Marti bb742ede 2011-09-19T01:54:32 Cleanup legal data 1. The license header is technically not valid if it doesn't have a copyright signature. 2. The COPYING file has been updated with the different licenses used in the project. 3. The full GPLv2 header in each file annoys me.
Carlos Martín Nieto 44daec42 2011-08-03T22:03:57 Bind the configuration and remotes to a repository Configurations when taken from a repository and remotes should be identifiable as coming from a particular repository. This allows us to reduce the amount of variables that the user has to keep track of. Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
Carlos Martín Nieto b22d1479 2011-06-16T17:46:06 Add git_repository_config API This function puts the global and repository configurations in one git_config object and gives it to the user. Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Vicent Marti b0b527e0 2011-05-20T03:20:12 config: Cleanup & renaming of the external API "git_config_backend" have been renamed to "git_config_file", which implements a generic interface to access a configuration file -- be it either on disk, from a DB or whatever mumbojumbo. I think this makes more sense.
Vicent Marti 8adbf2ed 2011-05-20T02:58:33 Rewrite `git_config_open_global` We have a lot of utility methods that make path building trivial. Use them!
Vicent Marti 0da2c700 2011-05-17T15:09:30 utils: Move git__str[n]tolower
Carlos Martín Nieto c0335005 2011-05-06T12:42:47 Move config to a backend structure Configuration options can come from different sources. Currently, there is only support for reading them from a flat file, but it might make sense to read it from a database at some point. Move the parsing code into src/config_file.c and create an include file include/git2/config_backend.h to allow for other backends to be developed. Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Carlos Martín Nieto 094aaaae 2011-05-05T15:16:15 config: store the section name separately The section and variable names use different rules, so store them as two different variables internally. This will simplify the configuration-writing code as well later on, but even with parsing, the code is simpler. Take this opportunity to add a variable to the list directly when parsing instead of passing through config_set.
Carlos Martín Nieto 6b45cb8a 2011-04-06T18:27:31 config: use and implement list macros Use list macros instead of manually changing the head and/or tail of the variable list.
Carlos Martín Nieto acab3bc4 2011-04-06T15:31:42 config: move str(n)tolower to the git__ namespace Non-static functions in a library should always have a prefix namespace. Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Carlos Martín Nieto 923fe455 2011-03-30T16:02:57 Add strtolower and strntolower functions As parts of variable names are case-sensitive, we need these functions. Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Carlos Martín Nieto e21881d1 2011-03-30T15:16:25 git_config: reorder fields according to use Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Carlos Martín Nieto dadc0158 2011-03-30T15:05:15 config: use a singly-linked list instead of a hash table Such a list preserves the order the variables were first read in which will be useful later for merging different data-sets. Furthermore, reading and writing out the same configuration should not reorganize the variables, which could happen when iterating through all the items in a hash table. A hash table is overkill for this small a data-set anyway. Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Carlos Martín Nieto 2974aa94 2011-03-30T11:30:40 Determine variable type at runtime Config variables should be interpreted at run-time, as we don't know if a zero means false or zero, or if yes means true or "yes". As a variable has no intrinsic type, git_cvtype is gone and the public API takes care of enforcing a few rules. Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Carlos Martín Nieto 6d7bb4e0 2011-03-29T17:35:02 Move git_cvar_type to include/git2/config.h Include it in src/config.h and fix the header name #define. Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Carlos Martín Nieto 238df559 2011-03-29T12:29:21 Rename git_config_{type,var} to git_cvar{_type,} Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Carlos Martín Nieto 5d4cd003 2011-03-28T17:02:45 Move the struct declaration outside config.c Signed-off-by: Carlos Martín Nieto <cmn@elego.de>