git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Amit Bakshi <ambakshi@gmail.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: git clone -c core.sharedRepository=group not working as expected (git v1.8.4 linux/osx)
Date: Tue, 24 Sep 2013 12:06:43 -0700	[thread overview]
Message-ID: <20130924190643.GL9464@google.com> (raw)
In-Reply-To: <CAFGOX=UiqqeZMxY_TCdA5ns0HpWxVUHHYmUBiEg+Zr1R5ZfHVA@mail.gmail.com>

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

Amit Bakshi wrote:

>  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)

  reply	other threads:[~2013-09-24 19:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-24 18:27 git clone -c core.sharedRepository=group not working as expected (git v1.8.4 linux/osx) Amit Bakshi
2013-09-24 19:06 ` Jonathan Nieder [this message]
2013-09-25  8:18   ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130924190643.GL9464@google.com \
    --to=jrnieder@gmail.com \
    --cc=ambakshi@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).