Add .gitconfig support

[maguro]

Not sure if a first class object to represent the .gitconfig file should be provided or if the global config information should be squirreled away inside config.Config. There is the ~/.gitignore_global file to consider as well.

It seems to me that a first class object and storer interface is the way to go. These are real physical entities and they should have their counterparts in the config package.

[orirawlings]

@maguro,

To clarify, are you referring to the system and global git configuration files (i.e. the ones accessed in git config via the --system and --global options)?

From git help config on my local OS X:

--global
           For writing options: write to global ~/.gitconfig file rather than the repository .git/config, write to $XDG_CONFIG_HOME/git/config file if this file
           exists and the ~/.gitconfig file doesn't.

           For reading options: read only from global ~/.gitconfig and from $XDG_CONFIG_HOME/git/config rather than from all available files.

           See also the section called "FILES".

--system
           For writing options: write to system-wide $(prefix)/etc/gitconfig rather than the repository .git/config.

           For reading options: read only from system-wide $(prefix)/etc/gitconfig rather than from all available files.

           See also the section called "FILES".

--local
           For writing options: write to the repository .git/config file. This is the default behavior.

           For reading options: read only from the repository .git/config rather than from all available files.

           See also the section called "FILES".

[orirawlings]

I think the config package is meant to be somewhat agnostic of what files are used to store the configuration (or even if files are used at all).

Currently there code to pull the --local .git/config file lives in the dotgit package. This is then wrapped up by the storage/filesystem.ConfigStorage implementation.

We probably do want to modify config somehow so that multiple Configs could be composed together (with more specific configs override settings in less specific configs).

[maguro]

I am speaking of the global and system configurations, which are not currently being read.

I did read through the config code. It seemed to me that it was rife with mixed concerns. I don't see how to cleanly accommodate, with parity, system and global configuration files without backward incompatible changes. More specifically, the marshaling code seems to assume that only a local config environment is in place; I hold a poor opinion about classes that have ser/der member functions.

Maybe we could have three internal structs, Local, Global, and System; making them "top-level" structs which would be fields of Config would have a number of advantages. The go-git code base would still get properties from the parent Config struct and the accessors would effect proper precedence. Such accessors could properly hunt down global ignores; the impetus for my endeavor.

The troublesome marshaling code would be limited to the local config file. I have no problem with that since anyone wanting to programmatically modify the global and system configurations could use some out of band mechanism. If such functionality were desired, things could be done slightly differently. Using io.Reader and io.Writer may be better than byte[]. Instances of Global and System would be passed in as a clone/open options. The ser/der bits for Global and System would be separate sets utility functions.

I don't see options for Plain*(). Maybe PlainOpenWith() and PlainInitWith() could be added. I think that OpenWith() and InitWith() would need to be added as well.

[maguro]

Actually, I'm quite fond of something like:

Open(s storage.Storer, worktree billy.Filesystem, opts ...RepositoryOption)

Then one could make calls such as

r, err := git.Open(s, workgree, WithGlobalConfig(), WithSystemConfig())

[maguro]

Can I get a 👍 from a Spaniard? :)

Is there anything you all would like to see before I start tinkering with this?

[maguro]

I'm going to start tinkering with this. Not sure when it will get done so if someone wants to work on this, feel free to ping me.

[mcuadros]

@maguro sorry we were the last week at Git Merge conference, you approach make sense.

About the Open function maybe we can create a new function call OpenWithOptions(*OpenOptions) since for sure we require more options, like: #765

[maguro]

To me

r, err := git.Open(s, worktree, WithGlobalConfig(), WithSystemConfig())

seems more elegant. If you don't want to use options you get the backwards compatible

r, err := git.Open(s, worktree)

[maguro]

What's the consensus on this?

[orirawlings]

For consistency with other API methods we should probably stick with the OpenOptions approach.

[maguro]

Yep. I will.