[RFC] Possibility to choose ~/.config/git/config instead of ~/.gitconfig

Hello,

As you know, git stores its configuration in ~/.gitconfig file and in other hidden files at the root of the user's directory.

We would like to have a configuration directory instead of all these  
configuration files by following the XDG specification because:
- not a lot of hidden files at the root, so better view
- one directory per software in ~/.config

We would like to give to users the possibility to store configuration in ~/.config/git/config file.

git would store its configuration in ~/.config/git/config file if:
- this file exists,
- and ~/.gitconfig file doesn't.
Otherwise git would store its configuration in ~/.gitconfig as usual.

If you don't create ~/.config/git/config, there is no change.

What do you think about it ?

I will send you a patch today.

Thanks,

Lucien KONG, Valentin DUPERRAY, Huynh Khoi Nguyen NGUYEN, Thomas NGUY, Franck JONAS

Grenoble INP ENSIMAG

Hi,

nguyenhu@minatec.inpg.fr wrote:

[...]

Sounds like a worthwhile goal, so I look forward to the patch. ;-)

What other hidden files at the root of the user's directory are you talking about?

Curious, Jonathan

Jonathan Nieder <jrnieder@gmail.com> writes:

A typical user configuration (or at least mine ;-) ) can include:

[core]
	excludesfile = ~/.gitignore
	attributesfile = ~/.gitattributes

Not having a default value for these two variables is a bit painful. For example, when I teach newbies not to version their *~ backup files, I'd like to grab their keyboard and type for them

  echo '*~' >> ~/.gitignore

but right now, it takes a bit more time than that (which multiplied by 35 students in a room is not negligible ;-) ).

Actually, I now remember trying to find a default value some time ago:

  http://thread.gmane.org/gmane.comp.version-control.git/133343

The conclusion essentially boiled down to "let's drop the patch until there's a clear consensus on what the default value should be", and "don't default to ~/.gitsomething, because it will be painful to migrate to a user config directory later".

Once it's official that the configuration is in stg like ~/.config/git/, we can start thinking about a default value for core.excludesfile and core.attributesfile, in the same directory (note: we're just talking about default values here, so users having set the variable explicitely won't be affected by the change).

Matthieu Moy wrote:

Ah, right, this line from .gitconfig: ;-)

	[core] excludesfile=~/.config/gitexcludes

[...]

Makes sense to me.

Thanks, Jonathan

On 25 May 2012 09:15,  <nguyenhu@minatec.inpg.fr> wrote:

This is, of course, highly OS dependent. Ironically, I'd say we need a setting in .gitconfig for it. :-)

There is also /etc(/default|/sysconfig|)/git/config to consider (perhaps for some settings that should be the same for everyone). Better yet, it would be nice if at least some settings could be part of the repository itself (whitespace handling e.g.).

Hi Hilco,

Hilco Wijbenga wrote:

The FILES section of git-config(1) might leave you happier. :)

Regarding $GIT_DIR/config, it says "The filename is of course relative to the repository root, not the working directory.". Is this out of date? (Cc-ing Peff and Duy.)

Jonathan

On 25 May 2012 10:42, Jonathan Nieder <jrnieder@gmail.com> wrote:

Indeed!

I'm sure it's not. Somehow, I had gotten it in my head that this wasn't possible. I am going to start using this right away. :-) Thanks!

From the FILES section of the git-config(1) manual:

	$GIT_DIR/config::
		Repository specific configuration file. (The filename is
		of course relative to the repository root, not the working
		directory.)

That's confusing because $GIT_DIR really is relative to the working directory.

	$ GIT_DIR=.git GIT_EDITOR='pwd; echo editing'
	$ export GIT_DIR GIT_EDITOR
	$ git config --edit --local
	/home/jrn/src/git/Documentation
	editing .git/config

It turns out that the comment is a remnant from older days when the heading said ".git/config" (which is indeed relative to the top of the worktree).

It was only when the heading was changed to refer more precisely to <git dir>/config (see v1.5.3.2~18, AsciiDoc tweak to avoid leading dot, 2007-09-14) that the parenthesis stopped making sense. Remove it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Hilco Wijbenga wrote:

You're right --- the current wording never made sense and is not an example of accurate documentation going stale with later behavior changes as I had suspected. Sorry for the noise.

Thanks, Jonathan

 Documentation/git-config.txt |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

On Fri, May 25, 2012 at 01:12:04PM -0500, Jonathan Nieder wrote:

Thanks for digging in the history for the answer.

This makes a lot more sense to me.

Acked-by: Jeff King <peff@peff.net>

-Peff

Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:

It is only worded awkwardly, I think. The above is merely trying to say that you do not place 'config' anywhere in the working tree; in other words, "repository" in the above refers to GIT_DIR, and the "root" means not inside refs/, objects/, or anywhere, just next to index, HEAD, etc.

Jonathan Nieder <jrnieder@gmail.com> writes:

This is a per-repository, but not "part of the repository" in the sense "files tracked by Git" (i.e. it's not fetched by git clone).

Having a $GIT_WORKTREE/.gitconfig file would be very nice, but raises a lot of security issues, so it's a much larger project (define which configuration values are allowed there, possibly take them into account at clone time, i.e. before checking out the files, and so on). Most likely out of the scope of my students' project ;-).

On Fri, May 25, 2012 at 07:54:06PM +0200, Matthieu Moy wrote:

Yes, I have proposed it in multiple forms, and the discussion always ends in "gross, it's too complex".

If you really want to do it, the recommended way at this point is:

  # review for any issues (1)
  less .gitconfig

  # assuming it's OK, copy into place (2)
  cp .gitconfig .git/config-from-upstream

  # include it
  git config include.path config-from-upstream

And then repeat steps (1) and (2) whenever you want to update from upstream. That fixes not only the security issues, but also means that you won't accidentally drop back to some antique bogus config when you "git checkout $some_old_version".

-Peff

Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:

As long as we make sure we have knobs for distro packagers and people building from the source to twist so that they can easily name the places they want us to read from and write to, what we decide in-tree does not matter. We default to ~/.gitconfig and /etc/gitconfig as before, and that is perfectly fine. We already have ETC_GITCONFIG, so the only thing it might be nicer to add is the build configurability of ~/.gitconfig file, no?

Junio C Hamano wrote:

If we were trying to solve a different problem ("my filesystem does not support filenames starting with '.' with more than three characters afterward") then I would agree, but in this case no. HOME directories are often shared between multiple machines, even machines with different operating systems.

If I understand correctly, the proposal that started this thread was to give people a chance to tidy their HOME directory by moving personal git configuration under ~/.config/git/. Git would detect it automatically. I think the main complication would be phasing in the change slowly and carefully so people helping each other with git problems do not get confused:

  "Why is this setting not taking effect?  It's in ~/.config/gitconfig
   just like it should be.  Oh, what git version do you have?"

and

  "Is there no .gitconfig?  Okay, we can assume all the default
   settings are in use.  Now let's..."

That's why I'd be happy to see how an initial patch approaches the transition, to see how it can be improved to happen smoothly.

Jonathan

Jonathan Nieder <jrnieder@gmail.com> writes:

So it is exactly "I do not want ~/.gitconfig, I want ~/.config/git", no?

That is something distro should be able to decide.

Junio C Hamano wrote:

Except that there is nothing distro-specific about it. Do you really want the config file to have a different name depending on whether one is using Debian, Fedora, Mac OS X, Gentoo, one of the various builds of git on Windows, Solaris, ...?

Besides, with my distro package maintainer hat on, I can tell you that switching the config file to ~/.config/git and not reading ~/.gitconfig would be a complete nonstarter. That would mean that the existing user configuration for everyone would just seem to disappear.

Once the code to read both files is written, why would one want that to be distro-specific and not something shared?

Hoping that clarifies a little, Jonathan

Jonathan Nieder <jrnieder@gmail.com> writes:

Not me personally.  But distros want to do that, it's their choice.

Absolutely. So don't choose to deliberately introduce backward incompatibliity. Problem solved.

Why is it bad to keep using ~/.gitconfig in the first place? The UNIX convention to exclude names that begin with dot is not working for you?

Junio C Hamano <gitster@pobox.com> writes:

It doesn't have to be backward incompatible. The proposal is to _allow_ users to have a ~/.config/git/config file, not to _force_ them to have one.

If Git reads both files, then ~/.gitconfig lovers can continue with it, and are not affected.

The "It's a convention" argument doesn't work here. XDG is also a rather widely used convention these days, so "why not follow the convention" can be used both in favor of ~/.gitconfig or ~/.config/git/config.

~/.gitconfig alone would not be a huge problem, although personnally hate it already. I like to version my handwritten configuration files, but I don't want my $HOME to be a git repository. I already have a ~/etc/ directory with my configuration files in it, and ~/.gitconfig is basically a symbolic link. I wouldn't have to re-structure my $HOME if I had a structured and standard configuration directory like ~/.config.

Now, the real issue is that we're starting to have several user-wide config files (core.excludesfile, core.attributesfile, maybe one day we'll want others like user-wide hooks?), and having multiple ~/.git<something> really feels wrong. Just like we have /etc/<file> for applications that have only one configuration file, and /etc/<directory> for ones who need more, it seems sensible to have a configuration directory for a user, not just a set of configuration files in $HOME.

Junio C Hamano wrote:

Ok, now you're making more sense. :)

I don't think anyone was proposing dropping support for .gitconfig. But:

Any patch to add support for ~/.config/git should of course take care to include a rationale that answers this question. (I am guessing that putting all user git configuration in one directory is part of the goal, and separating temporary files like ~/.fontconfig/*.cache* from configuration files like ~/.mutt/muttrc is another part.)

Ciao, Jonathan

Jonathan Nieder <jrnieder@gmail.com> writes:

That's another good thing with XDG (~/.config Vs ~/.cache/ for example), but I don't think Git would have anything user-wide that would not be configuration.

Matthieu Moy wrote:

Of course, but your home directory that you read with "ls -A" does. Putting configuration in ~/.config makes it easier to find amid all that noise.

That said, as Junio wrote before[1]:

That's what vim does --- its main configuration file is ~/.vimrc, and there are also some supporting files in ~/.config/vim/.

Wouldn't that be a good place to start?

Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/133343/focus=135921

Jonathan Nieder wrote:

Correction: I meant "also some supporting files in ~/.vim/".

Sorry for the noise. Jonathan

Jonathan Nieder <jrnieder@gmail.com> writes:

Yes. My sentence above was just replying to "separating temporary files" (i.e. putting stuff in ~/.cache/), I over-quoted your message.

Jonathan Nieder <jrnieder@gmail.com> writes:

I agree. Please don't encourage distro to make incompatible configuration changes.

On Fri, May 25, 2012 at 6:15 PM,  <nguyenhu@minatec.inpg.fr> wrote:

I like this, but it shouldn't be "~/.config", it should be $XDG_CONFIG_HOME.

Hi,

On Sat, May 26, 2012 at 12:45:52PM +0200, Felipe Contreras wrote:

If we do that what about a fallback to .config for operating systems that do not have XDG? E.g. Git for Windows would then also be able to benefit from that.

Cheers Heiko