libgit2/libgit2 — pull request #923 by yorah (2012-09-10 15:12:36+00:00)
Title: WIP - Add git_config_store support when handling config files

This is linked to libgit2/libgit2sharp#161 and libgit2/libgit2sharp#162.

The current code is currently in a very early/rough shape, but as always, I'm all for a little feedback if you have better ideas on how it should be done.

What I am aiming at is:
- Being able to specify a `GIT_CONFIG_STORE_XXX` when adding a file to a `git_config`
- Retrieving this information when getting a config value (this would be done by making the get methods return a `git_config_entry`, which contains the key, the value and the store of the config element)
- Being able to specify a config store when calling `git_config_delete` (should there be an overload that takes no config store?)
- Being able to specify a config store when calling `git_config_set_xxx` (should there be an overload that takes no config store?)
- Being able to specify a config store when calling `git_config_get_xxx` (the existing overload which takes no config store should keep looking in all config files based on the priority)

I already:
- Modified `git_config_add_file` and `git_config_add_file_ondisk` to get the config store information
- Modified `git_config_foreach` to send a `git_config_entry` in the callback

Current thoughts/interrogations that I have, and would love to hear your ideas:
- I think priority and config store are two different things. I tried playing with the idea of keeping only the config store notion, but I thought I didn't feel right
- Currently, it's possible to add several config files with the same priority. I'm not really willing to change that. However, this raises the question of "Can we have several config files with the same config store defined?" (if yes, would this mean returning EAMBIGUOUS in the get/set methods?)
- I currently have a `GIT_CONFIG_STORE_OTHER` (used in submodule.c for example)

I'm sure I'm missing other things yet. I will continue working on this and try to provide something consistent.

Thanks!