{"thread":{"id":"35198","subject":"Setting per-repository configuration for git","startedAt":"2013-10-25T07:12:35Z","lastAt":"2013-10-25T12:37:16Z","messageCount":3,"participants":["Jeremy Rosen","Jeff King","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"229504","messageId":"834511791.9670586.1382685155770.JavaMail.root@openwide.fr","threadId":"35198","inReplyTo":"884520645.9668515.1382684531443.JavaMail.root@openwide.fr","subject":"Setting per-repository configuration for git","fromName":"Jeremy Rosen","fromEmail":"jeremy.rosen@openwide.fr","sentAt":"2013-10-25T07:12:35Z","receivedAt":"2013-10-25T07:12:35Z","isPatch":false,"sender":{"key":"jeremy.rosen@openwide.fr","avatar":null},"body":"Hello everybody\n\nI am looking into the git configuration mechanism and there seem to \nbe a \"hole\" in use cases I'm trying to figure out...\n\n\ngit configurations can be saved at various places\n\n* /etc/gitconfig : system-wide configuration\n* ~/.gitconfig : user-wide configuration\n* .git/config : repository-wide configuration\n\nhowever I can't find a way to have the repository's configuration \nsaved and transmited with the repository in a way similar to how\n.gitignore is transmitted...\n\nSaving some configuration information within a repository is not \nunknown in git. .gitignore does it, and submodule configuration \ndoes it to.\n\nI think it's important to have a way to have configuration options\nbe saved in a repository (and overridable with .git/config which \nis local-repository only) because a lot of configurationoptions\n are meant to express repository policies (triangular workflows,\nmerge vs rebase, mail vs push) and it would make sense to have\nthem transmitted that way.\n\nKnowing how mature git is I can only assume that this has already\nbeen discussed and that there is a good reason not to do it. Is it\nbecause of hooks ? would it break something I don't see in git ?\n\ngit (the project) shouldn't enforce policies on repositories, but\nI think it makes sense for repositories to have a way to set default\npolicies on their clone...\n\nThx\n\nCordialement \n\nJérémy Rosen \n+33 (0)1 42 68 28 04\n\nfight key loggers : write some perl using vim \n\n\nOpen Wide Ingenierie\n\n23, rue Daviel\n75012 Paris - France\nwww.openwide.fr\n"},{"id":"229511","messageId":"20131025082513.GE17029@sigill.intra.peff.net","threadId":"35198","inReplyTo":"834511791.9670586.1382685155770.JavaMail.root@openwide.fr","subject":"Re: Setting per-repository configuration for git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-10-25T08:25:13Z","receivedAt":"2013-10-25T08:25:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 25, 2013 at 09:12:35AM +0200, Jeremy Rosen wrote:\n\n> however I can't find a way to have the repository's configuration \n> saved and transmited with the repository in a way similar to how\n> .gitignore is transmitted...\n> [...]\n> Knowing how mature git is I can only assume that this has already\n> been discussed and that there is a good reason not to do it. Is it\n> because of hooks ? would it break something I don't see in git ?\n\nThere are a few reasons.\n\nOne, there are security implications.  You can execute arbitrary code\nusing git config options (e.g., by defining diff helpers). While it's\ntrue that you often run the code that you fetch into your git\nrepository, you at least have an opportunity to verify it using git\ncommands before it is run.\n\nTwo, the config is not really tied to a specific revision in the same\nway that a .gitignore is. If I move to another branch, or checkout an\nold revision, I would want to use the .gitignore from the currently\nchecked-out commit. But git config does not typically work that way. If\nI am sight-seeing back to last year's history, I do not want to use a\ndifferent remote URL, or different diff settings, etc. So managing a\n.gitconfig directly in the repository has some ugly edge cases.\n\nI have proposed in the past letting config includes access git objects\ndirectly. Then a project could ship dedicated config in the \"config\"\nbranch, and you would always use the tip of that branch, even if you\nwere moving your working tree elsewhere in history. And if you want to\nprotect yourself from incoming config, you can point it to your _local_\nconfig branch, and only merge remote changes to it after verifying they\nare sane.\n\nThat would address both issues, but after some discussion, we realized\nthat you are really not any better off than simply pulling the data out\nof git and including it as a file. So something like:\n\n  1. Project ships recommended git config settings as `docs/gitconfig`.\n\n  2. User clones the repo.\n\n  3. User looks at `docs/gitconfig`, verifies that it's OK.\n\n  4. User copies `docs/gitconfig` to `.git/project-config`.\n\n  5. User points git at project config with `git config include.path\n     project-config`.\n\n  6. Periodically, user examines updates to `docs/gitconfig` and copies\n     it to `.git/project-config`.\n\nI don't know of any projects that do this, though, or even that ship a\nrecommended config. I don't know what one would put in such a config\nfile. Most settings are matters of personal preference, or local\nconfiguration for the machine.\n\n-Peff\n"},{"id":"229513","messageId":"loom.20131025T143218-801@post.gmane.org","threadId":"35198","inReplyTo":"20131025082513.GE17029@sigill.intra.peff.net","subject":"Re: Setting per-repository configuration for git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2013-10-25T12:37:16Z","receivedAt":"2013-10-25T12:37:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King <peff <at> peff.net> writes:\n> On Fri, Oct 25, 2013 at 09:12:35AM +0200, Jeremy Rosen wrote:\n> \n> > however I can't find a way to have the repository's configuration \n> > saved and transmited with the repository in a way similar to how\n> > .gitignore is transmitted...\n> > [...]\n\n> Two, the config is not really tied to a specific revision in the same\n> way that a .gitignore is. If I move to another branch, or checkout an\n> old revision, I would want to use the .gitignore from the currently\n> checked-out commit. But git config does not typically work that way. If\n> I am sight-seeing back to last year's history, I do not want to use a\n> different remote URL, or different diff settings, etc. So managing a\n> .gitconfig directly in the repository has some ugly edge cases.\n\nNb. *Mercurial* uses in repository .hgtags file for shared tags (instead\nof using separate transport mechanism, like Git does with refs, of\nwhich tags are special case).  Said file has to be treated in a special\nway, with some sharp corner-cases (e.g. committing a tag (sic!)).\n\n-- \nJakub Narębski\n"}]}