threads / discuss / 23135

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

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

## tl;dr

3 messages between Mar 22, 2010 and Mar 22, 2010.

replies: 2people: 2as markdown or json

Sitaram Chamarty· Mar 22, 2010, 06:30 UTC · lore

Hi all,

If you forget to use "--shared" on your (bare) repo, and now need to adjist it after the fact to make perms work ok, you ought to be able to just run "git init --bare --shared" and things should be fine.

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.
             */
            if (shared_repository) {
                    adjust_shared_perm(get_git_dir());
                    adjust_shared_perm(git_path("refs"));
                    adjust_shared_perm(git_path("refs/heads"));
                    adjust_shared_perm(git_path("refs/tags"));
            }

Ideally, we should do the same to:

hooks info objects objects/?? objects/info objects/pack

also. The othes are easy, but does git internals have a defined way of doing that objects/?? part or should it just be the long way (it's been ages since I did any C but I'd be willing to try...)

-- Sitaram

Junio C Hamano· Mar 22, 2010, 07:06 UTC · re: Sitaram Chamarty · lore

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

Sitaram Chamarty <sitaramc@gmail.com> writes:

Show 6 quoted lines

> 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".

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

Sitaram Chamarty· Mar 22, 2010, 09:45 UTC · lore

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

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