{"thread":{"id":"35007","subject":"git clone -c core.sharedRepository=group not working as expected (git v1.8.4 linux/osx)","startedAt":"2013-09-24T18:27:23Z","lastAt":"2013-09-25T08:18:44Z","messageCount":3,"participants":["Amit Bakshi","Jonathan Nieder","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"228166","messageId":"CAFGOX=UiqqeZMxY_TCdA5ns0HpWxVUHHYmUBiEg+Zr1R5ZfHVA@mail.gmail.com","threadId":"35007","inReplyTo":null,"subject":"git clone -c core.sharedRepository=group not working as expected (git v1.8.4 linux/osx)","fromName":"Amit Bakshi","fromEmail":"ambakshi@gmail.com","sentAt":"2013-09-24T18:27:23Z","receivedAt":"2013-09-24T18:27:23Z","isPatch":false,"sender":{"key":"ambakshi@gmail.com","avatar":"https://avatars.githubusercontent.com/u/32329?v=4"},"body":"Hi,\n\n I'm trying to use this to create a shared repo (group r/w), but it's\nnot working as expected. The help for git clone says \"Set a\nconfiguration variable in the newly-created repository; this takes\neffect immediately after the repository is initialized, but before the\nremote history is fetched or any files checked out.\", but I'm\ndefinitely not seeing this. Checked out files have umask applied.\n\n When I use the -c flag to git (ie, git -c core.sharedRepository=group\nclone ...) it does work as expected.\n\nNot a big deal just thought I'd report it.\n\n\nAmit\n"},{"id":"228168","messageId":"20130924190643.GL9464@google.com","threadId":"35007","inReplyTo":"CAFGOX=UiqqeZMxY_TCdA5ns0HpWxVUHHYmUBiEg+Zr1R5ZfHVA@mail.gmail.com","subject":"Re: git clone -c core.sharedRepository=group not working as expected (git v1.8.4 linux/osx)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-09-24T19:06:43Z","receivedAt":"2013-09-24T19:06:43Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(cc-ing Jeff King, \"git clone -c\" inventor)\nHi,\n\nAmit Bakshi wrote:\n\n>  I'm trying to use this to create a shared repo (group r/w), but it's\n> not working as expected. The help for git clone says \"Set a\n> configuration variable in the newly-created repository; this takes\n> effect immediately after the repository is initialized, but before the\n> remote history is fetched or any files checked out.\", but I'm\n> definitely not seeing this. Checked out files have umask applied.\n>\n> When I use the -c flag to git (ie, git -c core.sharedRepository=group\n> clone ...) it does work as expected.\n\nThanks for an interesting report.\n\nPart of the underlying problem is that unlike 'git init', 'git clone'\ndoes not accept a --shared=(true|false|group|...) option.  Worse, it\ndoes accept a --shared option, with a completely different meaning.\nNo better option names are coming immediately to mind, but perhaps\nsomeone on the list will have ideas that could let 'git clone' and\n'git init' use the same --share-repository=group option?\n\nIn any event, the lack of such an option steered you toward '-c'.\n\nAnother problem is that once the configuration is written, it is past\nthe point that some of the sharedrepository setting's effect would\nhave occured.  The repository, including worktree, object dirs, and so\non has already been created without g+w and setgid bits set.\n\nWorse, when we write the new configuration and then re-read it, we\nskip reading some repository-specific configuration\n(core.{repositoryformatversion,sharedrepository,bare,worktree})\non the assumption that we should already know what their values would\nbe.  That assumption is now wrong.\n\nI wonder if something like the following (just a sketch, completely\nuntested) would make sense.\n\ndiff --git i/builtin/clone.c w/builtin/clone.c\nindex 7ac677d..145a974 100644\n--- i/builtin/clone.c\n+++ w/builtin/clone.c\n@@ -856,7 +856,11 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \tinit_db(option_template, INIT_DB_QUIET);\n \twrite_config(&option_config);\n \n+\tif (option_bare)\n+\t\tgit_config_set(\"core.bare\", \"true\");\n+\n \tgit_config(git_default_config, NULL);\n+\tcheck_repository_format();\n \n \tif (option_bare) {\n \t\tif (option_mirror)\n"},{"id":"228194","messageId":"20130925081844.GA23238@sigill.intra.peff.net","threadId":"35007","inReplyTo":"20130924190643.GL9464@google.com","subject":"Re: git clone -c core.sharedRepository=group not working as expected (git v1.8.4 linux/osx)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-25T08:18:44Z","receivedAt":"2013-09-25T08:18:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 24, 2013 at 12:06:43PM -0700, Jonathan Nieder wrote:\n\n> Part of the underlying problem is that unlike 'git init', 'git clone'\n> does not accept a --shared=(true|false|group|...) option.  Worse, it\n> does accept a --shared option, with a completely different meaning.\n> No better option names are coming immediately to mind, but perhaps\n> someone on the list will have ideas that could let 'git clone' and\n> 'git init' use the same --share-repository=group option?\n\nPerhaps calling it something like --permissions would be good (IMHO,\nthat is more descriptive than \"--shared\" for \"git init\"). Then both can\nrespect it, and \"init\" maintains \"--shared\" for backwards compatibility.\n\nCalling it --shared-repository does match the config name, but I do not\nfind that name especially descriptive. But perhaps it is good enough,\nand consistency with the existing name is certainly a plus.\n\n> Another problem is that once the configuration is written, it is past\n> the point that some of the sharedrepository setting's effect would\n> have occured.  The repository, including worktree, object dirs, and so\n> on has already been created without g+w and setgid bits set.\n\nYes. This is as-documented for \"clone -c\", which claims to act after the\nrepository is initialized. That being said, I think it is less confusing\nfor the user for them to take effect as early as possible, so the user\ndoesn't have to worry.\n\nI cannot think off-hand of any case where the user would actually want\nthe delayed effect.\n\n> Worse, when we write the new configuration and then re-read it, we\n> skip reading some repository-specific configuration\n> (core.{repositoryformatversion,sharedrepository,bare,worktree})\n> on the assumption that we should already know what their values would\n> be.  That assumption is now wrong.\n\nYes, I think this is simply a bug in 84054f7 (clone: accept config\noptions on the command line), which assumed that any effects it had\nwould be picked up by the git_config() call.\n\n> I wonder if something like the following (just a sketch, completely\n> untested) would make sense.\n> \n> diff --git i/builtin/clone.c w/builtin/clone.c\n> index 7ac677d..145a974 100644\n> --- i/builtin/clone.c\n> +++ w/builtin/clone.c\n> @@ -856,7 +856,11 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n>  \tinit_db(option_template, INIT_DB_QUIET);\n>  \twrite_config(&option_config);\n>  \n> +\tif (option_bare)\n> +\t\tgit_config_set(\"core.bare\", \"true\");\n> +\n>  \tgit_config(git_default_config, NULL);\n> +\tcheck_repository_format();\n\nIf we call check_repository_format() again, we will pick up the new\nconfig. But I think we would still have to go back and fix the paths\ncreated by init_db.\n\nIt may be cleaner to teach init_db to add the initial config (and\noptionally add \"init -c\" for testing, though I do not think anyone\nparticularly cares in the real world).\n\n-Peff\n"}]}