{"thread":{"id":"3308","subject":"Configuration file musings","startedAt":"2006-02-12T13:45:44Z","lastAt":"2006-02-12T18:56:52Z","messageCount":2,"participants":["Mark Wooding","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15971","messageId":"slrnduuf08.518.mdw@metalzone.distorted.org.uk","threadId":"3308","inReplyTo":null,"subject":"Configuration file musings","fromName":"Mark Wooding","fromEmail":"mdw@distorted.org.uk","sentAt":"2006-02-12T13:45:44Z","receivedAt":"2006-02-12T13:45:44Z","isPatch":false,"sender":{"key":"mdw@distorted.org.uk","avatar":null},"body":"Having thought about things a bit, I've reached the conclusion that the\nconfiguration file $GIT_DIR/config is trying to hold (at least) three\nentirely different kinds of configuration.\n\n  * User configuration: basically, how I like GIT to work for me.  I\n    think that the way it represents my name in commit messages is user\n    configuration, as would be the behaviour of `git-commit PATH'.\n    Environment variables almost work for this, but they're a nuisance\n    to change.  This stuff ought to be somewhere in my home directory,\n    probably; though it would be useful to override temporarily, or on a\n    per-repository basis.\n\n  * Project configuration: how GIT should be supporting a particular\n    project.  The merge.summary flag is like this, I think: whether to\n    have summaries in merge messages is a policy decision to be taken\n    for a whole project, rather than something to be left to the whims\n    of individual developers.  Such settings probably to be propagated\n    through git-clone, git-fetch and so on.\n\n  * True repository configuration: how this particular repository ought\n    to behave.  I can't think of many examples off the top of my head,\n    but core.repositoryformatversion and core.filemode are the sorts of\n    things I'm thinking of.\n\nI'm not entirely sure where I'm going with this at the moment, and I\ndon't like some of the complexity which seems inherent in doing anything\nabout it, but I thought I'd stick my oar in anyway.\n\n-- [mdw]\n"},{"id":"15986","messageId":"7v4q34be2z.fsf@assigned-by-dhcp.cox.net","threadId":"3308","inReplyTo":"slrnduuf08.518.mdw@metalzone.distorted.org.uk","subject":"Re: Configuration file musings","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-12T18:56:52Z","receivedAt":"2006-02-12T18:56:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mark Wooding <mdw@distorted.org.uk> writes:\n\n> Having thought about things a bit, I've reached the conclusion that the\n> configuration file $GIT_DIR/config is trying to hold (at least) three\n> entirely different kinds of configuration.\n\nYes.  I've been somewhat bothered by that, but I did not ramble\non it too much because I could not say what exactly is _wrong_\nto have these things in the same file.\n\nExcept perhaps that pure user configuration could be further\nsplit out from per-repository user configuration to .gitconfig\nunder $HOME or something like that.  The former is things like\n\"I am Junio C Hamano no matter which project I work on\" the\nlatter is for example \"The e-mail address I use for this project\nis <junkio@cox>\".  But once we start dealing with more than one\nconfiguration file, you need one file taking precedence over the\nother and it appeared there is no single _right_ order.  The\nabove identity case is an example that it is better to make the\nconfig in repository to override $HOME one, but if you think\nlong enough I am sure you can come up with an example that you\nwould want to override repository one from $HOME one.\n"}]}