git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git clone -c core.sharedRepository=group not working as expected (git v1.8.4 linux/osx)

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Sep 24, 2013, 19:06 UTC
Message-ID
<20130924190643.GL9464@google.com>
In-Reply-To
<CAFGOX=UiqqeZMxY_TCdA5ns0HpWxVUHHYmUBiEg+Zr1R5ZfHVA@mail.gmail.com>

(cc-ing Jeff King, "git clone -c" inventor) Hi,

Amit Bakshi wrote:
Show 9 quoted lines
>  I'm trying to use this to create a shared repo (group r/w), but it's
> not working as expected. The help for git clone says "Set a
> configuration variable in the newly-created repository; this takes
> effect immediately after the repository is initialized, but before the
> remote history is fetched or any files checked out.", but I'm
> definitely not seeing this. Checked out files have umask applied.
>
> When I use the -c flag to git (ie, git -c core.sharedRepository=group
> clone ...) it does work as expected.
Thanks for an interesting report.

Part of the underlying problem is that unlike 'git init', 'git clone' does not accept a --shared=(true|false|group|...) option. Worse, it does accept a --shared option, with a completely different meaning. No better option names are coming immediately to mind, but perhaps someone on the list will have ideas that could let 'git clone' and 'git init' use the same --share-repository=group option?

In any event, the lack of such an option steered you toward '-c'.

Another problem is that once the configuration is written, it is past the point that some of the sharedrepository setting's effect would have occured. The repository, including worktree, object dirs, and so on has already been created without g+w and setgid bits set.

Worse, when we write the new configuration and then re-read it, we skip reading some repository-specific configuration (core.{repositoryformatversion,sharedrepository,bare,worktree}) on the assumption that we should already know what their values would be. That assumption is now wrong.

I wonder if something like the following (just a sketch, completely untested) would make sense.

diff --git i/builtin/clone.c w/builtin/clone.c
index 7ac677d..145a974 100644
--- i/builtin/clone.c
+++ w/builtin/clone.c
@@ -856,7 +856,11 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 	init_db(option_template, INIT_DB_QUIET);
 	write_config(&option_config);
 
+	if (option_bare)
+		git_config_set("core.bare", "true");
+
 	git_config(git_default_config, NULL);
+	check_repository_format();
 
 	if (option_bare) {
 		if (option_mirror)
Previous: Amit BakshiNext: Jeff King
Message 2 of 3 in “git clone -c core.sharedRepository=group not working as expected (git v1.8.4 linux/osx)”
  1. Amit BakshiSep 24, 2013
  2. Jonathan NiederSep 24, 2013
  3. Jeff KingSep 25, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.