patch, 2 partsIntroduce ~/.gitconfig

These two patches introduce the long awaited global config. Thanks to Paksy for pushing and starting it.

The first patch only does the reading part, while the second introduces the --no-local flag to git-repo-config.

There are three subjects for discussion:

- The name. I personally prefer .gitconfig, since we talk about the repo
  config all the time. But I have no strong feelings there.

- The --no-local flag could be implemented more cleanly, but also less
  elegantly, by introducing git_config_set_multivar_in_file(). I hesitated
  to do that, because there would be even more places replicating the
  global / local path resolution.

- With this, repo-config does no longer merit its name. What do people think
  about making it a builtin named "git config"? (Of course, nothing hinders
  us to keep the synonymous "repo-config" indefinitely...)

Ciao, Dscho

<Johannes.Schindelin@gmx.de> skrev:
 

Have you considered making ~/.gitconfig a directory? Maybe Git wants to store more data later.

Maybe, porcelains would want to use this directory, too. Gitk, tig, maybe Cogito at some time. One could have the configuration of all these git-related tools in a common namespace.

People like me, who work on a lot of different machines, could simply sync this directory across accounts and always work in their environment.

Sven

On 6/8/06, Sven Ekman <svekman@yahoo.se> wrote:

I second that. And it'd be nice if it was configurable through an environment variable, e.g., GIT_USER_CONFIG_HOME. A better name may be possible ;-).

  nikolai

Hi,

On Thu, 8 Jun 2006, Nikolai Weibull wrote:

I don't. What's wrong with the simple approach of a single config file? You can use a single tool for all the configuration, and do not need to care about anything.

After all, it is about _configuration_, not data storing. That is what $GIT_DIR/objects is for.

<sarcasm ignore=if-possible> Let's see. AFAIK all programs I know (including cvs and vim, for one) have a fixed name. Hmm. Perhaps this is for a reason? Like, to reduce confusion?

Alternatively, we could introduce a config variable "core.globalConfig" to see where the global config is. </sarcasm>

Ciao, Dscho

On 6/8/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Who said anything about something more than one configuration file? It's nice to have a directory if we later decide to store other kinds of files there as well, e.g., templates or some keyring information or something else, perhaps not well-suited for storing in an ini-like file.

That's hardly a very good reason.  It's not like you _have_ to use another name.

I keep as many configuration files as possible in ~/.local/etc/, as it simplifies keeping them in a Git repository. Here's an extract from my .zprofile:

XDG_CONFIG_HOME=~/.local/etc VIMINIT="so $XDG_CONFIG_HOME/vim/vimrc" INPUTRC=$XDG_CONFIG_HOME/inputrc INDENT_PROFILE=$XDG_CONFIG_HOME/indentrc SCREENRC=$XDG_CONFIG_HOME/screenrc GNUPGHOME=$XDG_CONFIG_HOME/gnupg IRBRC=$XDG_CONFIG_HOME/irbrc LFTP_HOME=$XDG_CONFIG_HOME/lftp MPLAYER_HOME=$XDG_CONFIG_HOME/mplayer GTK2_RC_FILES=$XDG_CONFIG_HOME/gtkrc

The only programs that don't play along, yet, are Mozilla, OpenSSH, and Subversion. (Mozilla is actually compile-time configurable.)

But I guess I should be providing a patch instead of just a bunch of reasoning for someone else to write one...

That is a very good idea. We wouldn't need an environment variable in that case.

  nikolai (who wonders if people can spot irony and sarcasm without extra help)

Hi,

On Thu, 8 Jun 2006, Nikolai Weibull wrote:

My point was: this has nothing to do with the "git config". Gitk, for example, has its own file there, ~/.gitk.

No they can't. You almost had me falling for it...

Ciao, Dscho

P.S.: I also wanted to mention that we could migrate all the config into an XML format. And maybe have an SQL backend instead of an object store.

On Thu, 2006-06-08 at 06:30, Johannes Schindelin wrote:

I like .gitconfig over .gitrc.

Could we have multiple levels, and have names that call out where it applies? Perhaps something like:

--repo into $GIT_DIR/.gitconfig <- current default, right? --home into ~/.gitconfig --site into /etc/gitconfig --share into /usr/share/git/config

My issue is that --no-local is vague and doesn't call out where it actually does go. There could be more than one different non-local place.

I have often forgotten the "repo-" part, and go looking for the "git config ..." man page and command. I think it should be "git config".

Perhaps, "git repo-config" would be "git config --repo ...." And "git config ..." would need an explict --home, --repo, --site type location flag from above?

But, hey, that's all pre-coffee.

jdl

On 6/8/06, Jon Loeliger <jdl@freescale.com> wrote:

BTW, if we go that far, maybe it makes more sense to implement a way to include files other config files? So repo-level config can (maybe implicitely) have an "include ~/.gitconfig" which in turn can "include /etc/gitconfig".

We could even do like C-preprocessor does: relative pathnames can be searched in a defined set of directores.

That's all overengineered, probably. I never needed .git/config, except for switching exec-bit (which I'd like to have on per-site basis, to be fair).

Hi,

On Thu, 8 Jun 2006, Jon Loeliger wrote:

The whole idea is that there are only two levels of configuration. Global (applies to all calls to git) and local (applies only to the repository).

Now, it makes sense to make settings overrideable in a certain order: If the global default does not match your needs in a particular case, override it. With "git-repo-config <key> <value>".

*However*, if you want to change the default, it makes sense to say "--no-local" or "--global", but I doubt that it makes any sense at all to access a certain finer level. For example, when would you possibly need to wrap in porcelain a method to query exactly which aliases are defined in /usr/local/share/git/config?

IOW if you want to edit /etc/gitconfig or something else you need admin permissions for with git-repo-config, you should look for another profession. Quickly.

post-coffee is pre-coffee.

Ciao, Dscho

Jon Loeliger wrote:

I like that too, wlthough --home might be named --user, and --share be named --predefined or --library.

Hi,

On Thu, 8 Jun 2006, Jakub Narebski wrote:

I am rather disinclined for the --share or --predefined flags, as these would only make sense for the administrator. And since this code was partly written by me, it eats small children.

Ciao, Dscho