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".

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.

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>

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>

"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.

We have a lot of utility methods that make path building trivial. Use
them!

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>

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.

Use list macros instead of manually changing the head and/or tail of
the variable list.

Non-static functions in a library should always have a prefix
namespace.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>

As parts of variable names are case-sensitive, we need these functions.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>

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>

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>

Include it in src/config.h and fix the header name #define.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>