{"thread":{"id":"32935","subject":"Proposal: sharing .git/config","startedAt":"2013-02-19T09:25:23Z","lastAt":"2013-03-18T11:48:05Z","messageCount":11,"participants":["Ramkumar Ramachandra","Thomas Rast","Duy Nguyen","Adam Spiers","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"209783","messageId":"CALkWK0npW6TLdMNd5_zw-RAB0bjF9DDoyAVSx4Zx=7AmvdEo3w@mail.gmail.com","threadId":"32935","inReplyTo":null,"subject":"Proposal: sharing .git/config","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-19T09:25:23Z","receivedAt":"2013-02-19T09:25:23Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nI have this itch where I want to share my remotes config between\nmachines.  In my fork, I should be able to specify where my upstream\nsources are, so remotes get set up automatically when I clone.  There\nare also other things in .git/config that would be nice to share, like\nwhether to do a --word-diff (why isn't it a configuration variable\nyet?) on the repository.  The only problem is that I have no clue how\nto implement this: I'm currently thinking a special remote ref?\n\nRam\n"},{"id":"209794","messageId":"87ip5otybp.fsf@pctrast.inf.ethz.ch","threadId":"32935","inReplyTo":"CALkWK0npW6TLdMNd5_zw-RAB0bjF9DDoyAVSx4Zx=7AmvdEo3w@mail.gmail.com","subject":"Re: Proposal: sharing .git/config","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2013-02-19T10:03:38Z","receivedAt":"2013-02-19T10:03:38Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> I have this itch where I want to share my remotes config between\n> machines.  In my fork, I should be able to specify where my upstream\n> sources are, so remotes get set up automatically when I clone.\n\nNote that you need to carefully pick only certain bits of the config, as\notherwise there are big security headaches.\n\n> There are also other things in .git/config that would be nice to\n> share, like whether to do a --word-diff (why isn't it a configuration\n> variable yet?)\n\nBecause that would break pretty much every script that uses git-diff?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"209800","messageId":"CALkWK0m--MbtNzGH9hNPCCLJWhv6rjF9Y=WQ4qnHUFnE61p6kw@mail.gmail.com","threadId":"32935","inReplyTo":"87ip5otybp.fsf@pctrast.inf.ethz.ch","subject":"Re: Proposal: sharing .git/config","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-19T10:24:32Z","receivedAt":"2013-02-19T10:24:32Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Thomas Rast wrote:\n> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n>\n>> I have this itch where I want to share my remotes config between\n>> machines.  In my fork, I should be able to specify where my upstream\n>> sources are, so remotes get set up automatically when I clone.\n>\n> Note that you need to carefully pick only certain bits of the config, as\n> otherwise there are big security headaches.\n\nRight.  So, we can just start with remotes for the moment?  Ideally,\nthere should be a way to specify which configuration options to\npublish.\n\n>> There are also other things in .git/config that would be nice to\n>> share, like whether to do a --word-diff (why isn't it a configuration\n>> variable yet?)\n>\n> Because that would break pretty much every script that uses git-diff?\n\ndiff.c already makes a differentiation between git_diff_ui_config()\nand git_diff_basic_config(); there are  configuration options that\nshould only be applied when the command is called interactively.\n"},{"id":"209803","messageId":"CACsJy8Ch70gZMkT7ScY3R-FNQU4QjtUe8UhoGRzE27cH9mu0HA@mail.gmail.com","threadId":"32935","inReplyTo":"CALkWK0npW6TLdMNd5_zw-RAB0bjF9DDoyAVSx4Zx=7AmvdEo3w@mail.gmail.com","subject":"Re: Proposal: sharing .git/config","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-02-19T10:34:43Z","receivedAt":"2013-02-19T10:34:43Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra\n<artagnon@gmail.com> wrote:\n> Hi,\n>\n> I have this itch where I want to share my remotes config between\n> machines.  In my fork, I should be able to specify where my upstream\n> sources are, so remotes get set up automatically when I clone.  There\n> are also other things in .git/config that would be nice to share, like\n> whether to do a --word-diff (why isn't it a configuration variable\n> yet?) on the repository.  The only problem is that I have no clue how\n> to implement this: I'm currently thinking a special remote ref?\n\nIf you check out the config file, then include.path should work. You\ncould add include.ref to point to a ref, but you need to deal with the\nattached security implications. This has been proposed before (and\nturned down, I think).\n-- \nDuy\n"},{"id":"209804","messageId":"87vc9osi3u.fsf@pctrast.inf.ethz.ch","threadId":"32935","inReplyTo":"CALkWK0m--MbtNzGH9hNPCCLJWhv6rjF9Y=WQ4qnHUFnE61p6kw@mail.gmail.com","subject":"Re: Proposal: sharing .git/config","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2013-02-19T10:39:17Z","receivedAt":"2013-02-19T10:39:17Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Thomas Rast wrote:\n>> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n>>> There are also other things in .git/config that would be nice to\n>>> share, like whether to do a --word-diff (why isn't it a configuration\n>>> variable yet?)\n>>\n>> Because that would break pretty much every script that uses git-diff?\n>\n> diff.c already makes a differentiation between git_diff_ui_config()\n> and git_diff_basic_config(); there are  configuration options that\n> should only be applied when the command is called interactively.\n\nIt still breaks every other use of diff unless you make the diff output\ndepend on whether the user runs directly at the terminal (possibly using\ngit's own paging).\n\nFor example, if you just say something like 'git diff >file' for\ninclusion in an email, you expect that to be a git-apply compatible\ndiff.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"209825","messageId":"CAOkDyE-at6jJZGV-3H4jEZhAsid41oqcQtEmad+5rwRhYiFUpQ@mail.gmail.com","threadId":"32935","inReplyTo":"CALkWK0npW6TLdMNd5_zw-RAB0bjF9DDoyAVSx4Zx=7AmvdEo3w@mail.gmail.com","subject":"Re: Proposal: sharing .git/config","fromName":"Adam Spiers","fromEmail":"git@adamspiers.org","sentAt":"2013-02-19T14:38:43Z","receivedAt":"2013-02-19T14:38:43Z","isPatch":false,"sender":{"key":"git@adamspiers.org","avatar":"https://avatars.githubusercontent.com/u/100738?v=4"},"body":"On Tue, Feb 19, 2013 at 9:25 AM, Ramkumar Ramachandra\n<artagnon@gmail.com> wrote:\n> Hi,\n>\n> I have this itch where I want to share my remotes config between\n> machines.  In my fork, I should be able to specify where my upstream\n> sources are, so remotes get set up automatically when I clone.  There\n> are also other things in .git/config that would be nice to share, like\n> whether to do a --word-diff (why isn't it a configuration variable\n> yet?) on the repository.  The only problem is that I have no clue how\n> to implement this: I'm currently thinking a special remote ref?\n\nI handle these kinds of configuration tasks out of band using mr,\nand it works pretty well:\n\n  https://github.com/aspiers/mr-config/#readme\n  https://github.com/aspiers/mr-config/blob/master/sh.d/git-remotes\n\nFood for thought ...\n"},{"id":"209828","messageId":"20130219153600.GA5338@sigill.intra.peff.net","threadId":"32935","inReplyTo":"CACsJy8Ch70gZMkT7ScY3R-FNQU4QjtUe8UhoGRzE27cH9mu0HA@mail.gmail.com","subject":"Re: Proposal: sharing .git/config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-19T15:36:00Z","receivedAt":"2013-02-19T15:36:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote:\n\n> On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra\n> <artagnon@gmail.com> wrote:\n> > Hi,\n> >\n> > I have this itch where I want to share my remotes config between\n> > machines.  In my fork, I should be able to specify where my upstream\n> > sources are, so remotes get set up automatically when I clone.  There\n> > are also other things in .git/config that would be nice to share, like\n> > whether to do a --word-diff (why isn't it a configuration variable\n> > yet?) on the repository.  The only problem is that I have no clue how\n> > to implement this: I'm currently thinking a special remote ref?\n> \n> If you check out the config file, then include.path should work. You\n> could add include.ref to point to a ref, but you need to deal with the\n> attached security implications. This has been proposed before (and\n> turned down, I think).\n\nHere's the patch:\n\n  http://article.gmane.org/gmane.comp.version-control.git/189144\n\nThe basic argument against it is that you would _not_ want to do:\n\n  $ git config include.ref origin/config\n\nbecause it's unsafe (you immediately start using config fetched from the\nremote, before you even get a chance to inspect it). So the recommended\nway to use it is:\n\n  $ git config include.ref config\n  $ git show origin/config ;# make sure it looks reasonable\n  $ git update-ref refs/config origin/config\n\n  [time passes...]\n\n  $ git fetch\n  $ git diff config origin/config ;# inspect changes\n  $ git update-ref refs/config origin/config\n\nBut it was pointed out that you could also just do:\n\n  $ git config include.ref upstream-config\n  $ git show origin/config ;# make sure it looks reasonable\n  $ git show origin/config >.git/upstream-config\n\nand so forth. There are some ways that a pure ref can be more\nconvenient (e.g., if you are carrying local changes on top of the\nupstream config and want to merge), but ultimately, you can replicate\nany include.ref workflow with include.path by adding a \"deploy\" step\nwhere you copy the file into $GIT_DIR.\n\n-Peff\n"},{"id":"211070","messageId":"CALkWK0kZiYmbh-dSr-c2mzK2Mzhf3iZ_T3hFNuR57F0b5tptGw@mail.gmail.com","threadId":"32935","inReplyTo":"20130219153600.GA5338@sigill.intra.peff.net","subject":"Re: Proposal: sharing .git/config","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-11T19:31:08Z","receivedAt":"2013-03-11T19:31:08Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote:\n>\n>> On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra\n>> <artagnon@gmail.com> wrote:\n>> > Hi,\n>> >\n>> > I have this itch where I want to share my remotes config between\n>> > machines.  In my fork, I should be able to specify where my upstream\n>> > sources are, so remotes get set up automatically when I clone.  There\n>> > are also other things in .git/config that would be nice to share, like\n>> > whether to do a --word-diff (why isn't it a configuration variable\n>> > yet?) on the repository.  The only problem is that I have no clue how\n>> > to implement this: I'm currently thinking a special remote ref?\n>>\n>> If you check out the config file, then include.path should work. You\n>> could add include.ref to point to a ref, but you need to deal with the\n>> attached security implications. This has been proposed before (and\n>> turned down, I think).\n>\n> Here's the patch:\n>\n>   http://article.gmane.org/gmane.comp.version-control.git/189144\n>\n> The basic argument against it is that you would _not_ want to do:\n>\n>   $ git config include.ref origin/config\n>\n> because it's unsafe (you immediately start using config fetched from the\n> remote, before you even get a chance to inspect it). So the recommended\n> way to use it is:\n>\n>   $ git config include.ref config\n>   $ git show origin/config ;# make sure it looks reasonable\n>   $ git update-ref refs/config origin/config\n>\n>   [time passes...]\n>\n>   $ git fetch\n>   $ git diff config origin/config ;# inspect changes\n>   $ git update-ref refs/config origin/config\n>\n> But it was pointed out that you could also just do:\n>\n>   $ git config include.ref upstream-config\n>   $ git show origin/config ;# make sure it looks reasonable\n>   $ git show origin/config >.git/upstream-config\n>\n> and so forth. There are some ways that a pure ref can be more\n> convenient (e.g., if you are carrying local changes on top of the\n> upstream config and want to merge), but ultimately, you can replicate\n> any include.ref workflow with include.path by adding a \"deploy\" step\n> where you copy the file into $GIT_DIR.\n\nThis seems to be unnecessarily complex and inelegant.  Maybe this\nfunctionality is best managed as a separate git repository: `repo`\nfrom depot_tools uses a manifest repository containing all the project\nmetadata.  Maybe we can extend it/ write an more general version?\n"},{"id":"211105","messageId":"20130312085342.GA11340@sigill.intra.peff.net","threadId":"32935","inReplyTo":"CALkWK0kZiYmbh-dSr-c2mzK2Mzhf3iZ_T3hFNuR57F0b5tptGw@mail.gmail.com","subject":"Re: Proposal: sharing .git/config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-12T08:53:42Z","receivedAt":"2013-03-12T08:53:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 12, 2013 at 01:01:08AM +0530, Ramkumar Ramachandra wrote:\n\n> > But it was pointed out that you could also just do:\n> >\n> >   $ git config include.ref upstream-config\n> >   $ git show origin/config ;# make sure it looks reasonable\n> >   $ git show origin/config >.git/upstream-config\n> >\n> > and so forth. There are some ways that a pure ref can be more\n> > convenient (e.g., if you are carrying local changes on top of the\n> > upstream config and want to merge), but ultimately, you can replicate\n> > any include.ref workflow with include.path by adding a \"deploy\" step\n> > where you copy the file into $GIT_DIR.\n> \n> This seems to be unnecessarily complex and inelegant.  Maybe this\n> functionality is best managed as a separate git repository: `repo`\n> from depot_tools uses a manifest repository containing all the project\n> metadata.  Maybe we can extend it/ write an more general version?\n\nI don't think you can avoid the 3-step problem and retain the safety in\nthe general case.  Forgetting implementation details for a minute, you\nhave either a 1-step system:\n\n  1. Fetch and start using config from the remote.\n\nwhich is subject to fetching and executing malicious config, or:\n\n  1. Fetch config from remote.\n  2. Inspect it.\n  3. Integrate it into the current config.\n\nWe can automate the sequence to remove as much friction as possible, but\nfundamentally step 2 requires some effort from the user.  Moving the\nconfig to a separate repo does not get rid of those steps.  The user\neither does not look at the config before using it, in which case we are\nno better than the 1-step scenario, or they do, in which case they are\nreplicating the 3-step scenario.\n\nThe other alternative is to automate step 2. The simplest way would be\nto have a whitelist of \"ok to share\" config, that would not include\nthings like diff.external that can run arbitrary code. I don't know\nwhether that would make the system too limited for what people want to\ndo. Do we have a concrete example of what config people would like to\nshare in this manner?\n\n-Peff\n"},{"id":"211552","messageId":"CALkWK0nWXCO_EXfx69m8XbrFe=ABBodPdFbSrS9v3VqgfbnQ+w@mail.gmail.com","threadId":"32935","inReplyTo":"20130312085342.GA11340@sigill.intra.peff.net","subject":"Re: Proposal: sharing .git/config","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-18T09:00:23Z","receivedAt":"2013-03-18T09:00:23Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> I don't think you can avoid the 3-step problem and retain the safety in\n> the general case.  Forgetting implementation details for a minute, you\n> have either a 1-step system:\n>\n>   1. Fetch and start using config from the remote.\n>\n> which is subject to fetching and executing malicious config, or:\n>\n>   1. Fetch config from remote.\n>   2. Inspect it.\n>   3. Integrate it into the current config.\n\nI don't understand your emphasis on step 2.  Isn't the configuration\nwritten by me?  Why would it be malicious?\n\nI've just started thinking about how to design something that will\nallow us to share configuration elegantly [1].  Essentially, the\nmetadata repository will consist of *.layout files, one for each\nrepository to clone, containing the .git/config to write after cloning\nthat repository.  So, a git.layout might look like:\n\n[layout]\n\tdirectory = git\n[remote \"origin\"]\n\turl = git://github.com/git/git\n[remote \"ram\"]\n\turl = git@github.com:artagnon/git\n[remote \"junio\"]\n\turl = git://github.com/gitster/git\n\nAs you can see the [layout] is a special section which will tell our\nfetcher where to place the repository.  Everything else is meant to be\ninserted into the repository's .git/config.  However, I can foresee a\nproblem in scaling: when I ask a specific directory like a/b/c to be\npopulated (equivalent of repo sync `a/b/c`), it'll have to parse the\nlayout.directory variable of all the .layout files, and this can be\nslow.  So, maybe we should have a special _manifest.layout listing all\nthe paths?\n\nFurther, I see this as a way to work with projects that would\notherwise require nested submodules like the Android project.  What do\nyou think?\n\n[1]: https://github.com/artagnon/src.layout\n"},{"id":"211558","messageId":"20130318114805.GB14789@sigill.intra.peff.net","threadId":"32935","inReplyTo":"CALkWK0nWXCO_EXfx69m8XbrFe=ABBodPdFbSrS9v3VqgfbnQ+w@mail.gmail.com","subject":"Re: Proposal: sharing .git/config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-18T11:48:05Z","receivedAt":"2013-03-18T11:48:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 18, 2013 at 02:30:23PM +0530, Ramkumar Ramachandra wrote:\n\n> Jeff King wrote:\n> > I don't think you can avoid the 3-step problem and retain the safety in\n> > the general case.  Forgetting implementation details for a minute, you\n> > have either a 1-step system:\n> >\n> >   1. Fetch and start using config from the remote.\n> >\n> > which is subject to fetching and executing malicious config, or:\n> >\n> >   1. Fetch config from remote.\n> >   2. Inspect it.\n> >   3. Integrate it into the current config.\n> \n> I don't understand your emphasis on step 2.  Isn't the configuration\n> written by me?  Why would it be malicious?\n\nMaybe I am misunderstanding the use case, but when people talk about\nshare config, they are often talking about pushing project-wide config\nout to developers. So the config is not necessarily written by you, but\nby somebody who had write access to the upstream repository.\n\nThe obvious counterpoint is that people usually run \"make\" right after\nfetching, so they are trusting what they fetched already. And the\ncounter-counterpoint is that yes, that's true, but at least with the\n\"make\" case they can use git to inspect the differences before running\nthem. You may be able to tell that this is not the first time this\ndiscussion has happened. :)\n\nPersonally, I do not think it is the end of the world for people to opt\ninto the \"automatically fetch and respect config\" method for certain\nrepositories (and that's why I wrote include.ref support a while ago).\nIt's a security tradeoff that the user may want to make. But I also\nrespect the argument that we should not be endorsing risky behavior by\nadvertising such a feature (especially when the risk is quite subtle, as\nmany users may not realize that git config can execute arbitrary code).\n\n> I've just started thinking about how to design something that will\n> allow us to share configuration elegantly [1].  Essentially, the\n> metadata repository will consist of *.layout files, one for each\n> repository to clone, containing the .git/config to write after cloning\n> that repository.  So, a git.layout might look like:\n> \n> [layout]\n> \tdirectory = git\n> [remote \"origin\"]\n> \turl = git://github.com/git/git\n> [remote \"ram\"]\n> \turl = git@github.com:artagnon/git\n> [remote \"junio\"]\n> \turl = git://github.com/gitster/git\n> \n> As you can see the [layout] is a special section which will tell our\n> fetcher where to place the repository.  Everything else is meant to be\n> inserted into the repository's .git/config.  However, I can foresee a\n> problem in scaling: when I ask a specific directory like a/b/c to be\n> populated (equivalent of repo sync `a/b/c`), it'll have to parse the\n> layout.directory variable of all the .layout files, and this can be\n> slow.  So, maybe we should have a special _manifest.layout listing all\n> the paths?\n> \n> Further, I see this as a way to work with projects that would\n> otherwise require nested submodules like the Android project.  What do\n> you think?\n\nYeah, reading your layout description, this is less about git config in\nparticular, and more about managing hierarchies of repos. Which I think\nis a fine thing to do, and is a sensible place to put config management\n(since you are probably executing arbitrary code as part of the layout\ntool anyway). But I don't have a real opinion on the design of such a\ntool. I have used repo only once or twice to deal with Android. For my\nown menagerie of small repos, I have a hacky custom tool that is mostly\nabout deciding when there are items to be committed, pushed, or fetched\nin each repo; I never found the need to handle git config at all.\n\n-Peff\n"}]}