Fwd: running "git init --shared" on an existing repo

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Mar 22, 2010, 09:45 UTC
Message-ID: <2e24e5b91003220245p7de5cd7dqc5f21230c244a268@mail.gmail.com>
In-Reply-To: <2e24e5b91003220244v2d21bf3ay5b18d1ef40781be2@mail.gmail.com>

oops-- forgot to "reply all"; so it only went to Junio...

---------- Forwarded message ----------
From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Mon, Mar 22, 2010 at 3:14 PM
Subject: Re: running "git init --shared" on an existing repo
To: Junio C Hamano <gitster@pobox.com>

On Mon, Mar 22, 2010 at 12:36 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 13 quoted lines

> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> And it seems there was a beginning made.  builtin/init-db.c at line 220 says:
>>
>>             /*
>>              * We would have created the above under user's umask -- under
>>              * shared-repository settings, we would need to fix them up.
>>              */
>
> That "the above" refers to "in this process that created the repository
> directory and populated it halfway by calling copy_templates()", and never
> "some time ago by some other process that created the repository, in which
> this process is now being run", so it is not fair to say "a beginning".

Possible, but the fact remains that when you do that "some time ago", and then come back and do this, it *does* fix up the perms of refs, refs/heads, and refs/tags.

> You would need to run "find $GIT_DIR -print0 | xargs -0 chown/mod ..." or
> a moral equivalent of it, I guess.  Shouldn't be a rocket surgery ;-)

true... the toruble with using perl for years is that it sorta spoils you; I need to actually *think* now, despite it not being rocket surgery :-)

I will send a patch by and by... I wonder if cheating and calling system("find <whatever> -type d -exec chmod g+s") will be acceptable ;-)

-- Sitaram

-- 
Sitaram