Re: Error: unable to unlink ... when using "git gc"

[re-adding git@vger; please keep discussion on-list so everyone can
benefit from the result]

On Tue, Jan 06, 2009 at 03:52:12PM +0800, Johnny Lee wrote:

Thanks Peff, I've checked the permission of .git/objects/16, it's
created by another user and thus I have no permission to remove it.

In fact, this is coming from a previous bad practice on setting up a
collaboration repository on a SSH server, here is what I've done so
far:
[...]
7. Then the user "git" has changed mode for all the files under .git
to writable.

8. This time, user "johnny" can push successfully.

If you are going to have multiple users sharing a repository, generally
they should be in the same group and the core.sharedrepository config
option should be set (see "git help config", or the "shared" option to
git-init).

I've never used that personally, though. I have always just used POSIX
ACLs, with a default ACL on each directory giving access to everyone.
E.g. (off the top of my head):

  for user in user1 user2 user3; do
    setfacl -R -m u:$user:rwX -m d:u:$user:rwX /path/to/repo
  done

-Peff

Ooops, forgot to cc to the mailing list.

Thanks for your sharing Peff, I'm going to check these stuffs out and
get back with any findings.

Regards,
Johnny

On Tue, Jan 6, 2009 at 4:03 PM, Jeff King [off-list ref] wrote:

[re-adding git@vger; please keep discussion on-list so everyone can
benefit from the result]

On Tue, Jan 06, 2009 at 03:52:12PM +0800, Johnny Lee wrote:

quoted

Thanks Peff, I've checked the permission of .git/objects/16, it's
created by another user and thus I have no permission to remove it.

In fact, this is coming from a previous bad practice on setting up a
collaboration repository on a SSH server, here is what I've done so
far:
[...]
7. Then the user "git" has changed mode for all the files under .git
to writable.

8. This time, user "johnny" can push successfully.

If you are going to have multiple users sharing a repository, generally
they should be in the same group and the core.sharedrepository config
option should be set (see "git help config", or the "shared" option to
git-init).

I've never used that personally, though. I have always just used POSIX
ACLs, with a default ACL on each directory giving access to everyone.
E.g. (off the top of my head):

 for user in user1 user2 user3; do
   setfacl -R -m u:$user:rwX -m d:u:$user:rwX /path/to/repo
 done

-Peff

-- 
we all have our crosses to bear

On 2009-01-06, Jeff King [off-list ref] wrote:

If you are going to have multiple users sharing a repository, generally
they should be in the same group and the core.sharedrepository config
option should be set (see "git help config", or the "shared" option to
git-init).

I've never used that personally, though. I have always just used POSIX
ACLs, with a default ACL on each directory giving access to everyone.
E.g. (off the top of my head):

  for user in user1 user2 user3; do
    setfacl -R -m u:$user:rwX -m d:u:$user:rwX /path/to/repo
  done

If you're not worried about the finer-grained access control
that acl(5) gives you, just do what "git init
--shared=group" does:

    git config core.sharedrepository 1 # as mentioned above
    chmod g+ws .git

Now set the group to something (I use "gitpushers" ;-)

    chgrp -R gitpushers .git

amd make sure all your users are part of that group.

Works fine for small teams...

Copy that.

Thanks Sitaram.

We also plan to do it in this way, just a small wondering that it
looks a kind of workaround instead of a more graceful solution.

Regards,
Johnny

On Tue, Jan 6, 2009 at 7:57 PM, Sitaram Chamarty [off-list ref] wrote:

On 2009-01-06, Jeff King [off-list ref] wrote:

quoted

If you are going to have multiple users sharing a repository, generally
they should be in the same group and the core.sharedrepository config
option should be set (see "git help config", or the "shared" option to
git-init).

I've never used that personally, though. I have always just used POSIX
ACLs, with a default ACL on each directory giving access to everyone.
E.g. (off the top of my head):

  for user in user1 user2 user3; do
    setfacl -R -m u:$user:rwX -m d:u:$user:rwX /path/to/repo
  done

If you're not worried about the finer-grained access control
that acl(5) gives you, just do what "git init
--shared=group" does:

   git config core.sharedrepository 1 # as mentioned above
   chmod g+ws .git

Now set the group to something (I use "gitpushers" ;-)

   chgrp -R gitpushers .git

amd make sure all your users are part of that group.

Works fine for small teams...

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
we all have our crosses to bear

On 2009-01-06, Johnny Lee [off-list ref] wrote:

On Tue, Jan 6, 2009 at 7:57 PM, Sitaram Chamarty [off-list ref] wrote:

quoted

If you're not worried about the finer-grained access control
that acl(5) gives you, just do what "git init
--shared=group" does:

   git config core.sharedrepository 1 # as mentioned above
   chmod g+ws .git

Now set the group to something (I use "gitpushers" ;-)

   chgrp -R gitpushers .git

amd make sure all your users are part of that group.

We also plan to do it in this way, just a small wondering that it
looks a kind of workaround instead of a more graceful solution.

I wouldn't consider it a workaround.  It uses normal Unix
permissions the way they were designed to, including setgid
for directories.

Actually, I am yet to come up with a situation where I
actually needed ACLs, though they are more generalised, and
fine-grained.

And the maint is all eminently scriptable.

On Tuesday 06 January 2009, Sitaram Chamarty [off-list ref] wrote 
about 'Re: Error: unable to unlink ... when using "git gc"':

On 2009-01-06, Jeff King [off-list ref] wrote:

quoted

If you are going to have multiple users sharing a repository, generally
they should be in the same group and the core.sharedrepository config
option should be set (see "git help config", or the "shared" option to
git-init).

If you're not worried about the finer-grained access control
that acl(5) gives you, just do what "git init
--shared=group" does:

   git config core.sharedrepository 1 # as mentioned above
   chmod g+ws .git

Now set the group to something (I use "gitpushers" ;-)

   chgrp -R gitpushers .git

amd make sure all your users are part of that group.

Works fine for small teams...

ISTR this breaking here when someone on the team had a umask like 077 and 
was using file:// or ssh:// to push.  I tended up "fixing" things with a 
cronjob, (which is a bit of a hack) IIRC.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

On 2009-01-07, Boyd Stephen Smith Jr. [off-list ref] wrote:

On Tuesday 06 January 2009, Sitaram Chamarty [off-list ref] wrote=20

quoted

   chmod g+ws .git

Now set the group to something (I use "gitpushers" ;-)

   chgrp -R gitpushers .git

ISTR this breaking here when someone on the team had a umask like 077 and=20
was using file:// or ssh:// to push.  I tended up "fixing" things with a=20
cronjob, (which is a bit of a hack) IIRC.

That doesn't sound right.  "git help init" says:
 - 0xxx: 0xxx is an octal number and each file will have mode 0xxx
 - 0xxx will override users umask(2) value, and thus, users
   with a safe umask (0077) can use this option
 - 0660 is equivalent to group.

So when you say "group", you're saying "0660", and when you
say "0660", you're overriding users umask value.

I sorta-kinda tested it (some output of the "find|xargs ls"
is snipped for brevity):

    $ mkdir umt;cd umt
    $ umask         
    0022                                 
    $ git init --shared=group
    Initialized empty shared Git repository in /home/sitaram/t/umt/.git/
    (reverse-i-search)`find': sfind f|ack .git|map -x du -sk |sort -n
    $ find . -type d|xargs ls -ald     
    drwxr-xr-x 3 sitaram sitaram 4096 2009-01-07 15:59 .             
    drwxrwsr-x 7 sitaram sitaram 4096 2009-01-07 15:59 ./.git        

    $ dummy_commit                   
    Created initial commit afb2645: file-30824 at Wed Jan  7 15:59:23 IST 2009
     1 files changed, 1 insertions(+), 0 deletions(-)
     create mode 100644 file-30824
    $ find . -type d|xargs ls -ald
    drwxr-xr-x 3 sitaram sitaram 4096 2009-01-07 15:59 .
    drwxrwsr-x 9 sitaram sitaram 4096 2009-01-07 15:59 ./.git
    drwxrwsr-x 2 sitaram sitaram 4096 2009-01-07 15:59 ./.git/objects/a7
    drwxrwsr-x 2 sitaram sitaram 4096 2009-01-07 15:59 ./.git/objects/af
    drwxrwsr-x 2 sitaram sitaram 4096 2009-01-07 15:59 ./.git/objects/ca

    $ umask 077
    $ jeeves dummy_commit
    Created commit 232f157: file-3025 at Wed Jan  7 15:59:36 IST 2009
     1 files changed, 1 insertions(+), 0 deletions(-)
     create mode 100644 file-3025
    $ find . -type d|xargs ls -ald
    drwxr-xr-x  3 sitaram sitaram 4096 2009-01-07 15:59 .
    drwxrwsr-x  9 sitaram sitaram 4096 2009-01-07 15:59 ./.git
    drwxrws---  2 sitaram sitaram 4096 2009-01-07 15:59 ./.git/objects/23
    drwxrwsr-x  2 sitaram sitaram 4096 2009-01-07 15:59 ./.git/objects/a7
    drwxrws---  2 sitaram sitaram 4096 2009-01-07 15:59 ./.git/objects/a8
    drwxrwsr-x  2 sitaram sitaram 4096 2009-01-07 15:59 ./.git/objects/af
    drwxrws---  2 sitaram sitaram 4096 2009-01-07 15:59 ./.git/objects/c7
    drwxrwsr-x  2 sitaram sitaram 4096 2009-01-07 15:59 ./.git/objects/ca

On 2009-01-07, Sitaram Chamarty [off-list ref] wrote:

    $ dummy_commit                   
    $ jeeves dummy_commit

err, helper functions.  Should have mentioned.

I do a lot of playing around with git :-)

On Wednesday 2009 January 07 04:55:56 you wrote:

On 2009-01-07, Boyd Stephen Smith Jr. [off-list ref] wrote:

quoted

On Tuesday 06 January 2009, Sitaram Chamarty [off-list ref]
wrote=20

quoted

   chmod g+ws .git

Now set the group to something (I use "gitpushers" ;-)

   chgrp -R gitpushers .git

ISTR this breaking here when someone on the team had a umask like 077
and=20 was using file:// or ssh:// to push.  I tended up "fixing" things
with a=20 cronjob, (which is a bit of a hack) IIRC.

That doesn't sound right.  "git help init" says:
 - 0xxx: 0xxx is an octal number and each file will have mode 0xxx
 - 0xxx will override users umask(2) value, and thus, users
   with a safe umask (0077) can use this option
 - 0660 is equivalent to group.

So when you say "group", you're saying "0660", and when you
say "0660", you're overriding users umask value.

Very good then.  It is from when I was significantly less experienced in using 
git and managing repos, so I may have forgotten to use the correct options OR 
it could just have been the version of git I was using (1.4.4.4, IIRC) -- 
still using that in at least one place, as it is the current version in 
Debian Etch.

It's good to know it works properly now, if all the right switches are set.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

On Wednesday 2009 January 07 12:00:22 Sitaram Chamarty wrote:

On 2009-01-07, Boyd Stephen Smith Jr. [off-list ref] wrote:

quoted

On Wednesday 2009 January 07 04:55:56 you wrote:

quoted

So when you say "group", you're saying "0660", and when you
say "0660", you're overriding users umask value.

it could just have been the version of git I was using (1.4.4.4, IIRC)
-- still using that in at least one place, as it is the current
version in Debian Etch.

1.4.4.4 is 2 years and 2 days old today!  [I've heard
stories about Debian, but never thought it was this
conservative!]

Once a stable is released, no new versions of packages come in, only 
backported bug and security fixes.  The pre-release freeze also limits new 
versions from being considered.  Lenny should be out RSN, so I can move up to 
1.5.6.5. :)

$ apt-cache policy git-core
git-core:
  Installed: 1:1.4.4.4-4
  Candidate: 1:1.4.4.4-4
  Version table:
     1:1.6.0.6-1 0
        300 http://localhost experimental/main Packages
     1:1.5.6.5-2 0
        700 http://localhost testing/main Packages
        500 http://localhost unstable/main Packages
     1:1.5.6.5-1~bpo40+1 0
        800 http://localhost etch-backports/main Packages
 *** 1:1.4.4.4-4 0
        900 http://localhost stable/main Packages
        100 /var/lib/dpkg/status
     1:1.4.4.4-2.1+etch1 0
        900 http://localhost stable/updates/main Packages
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

On Tue, Jan 06, 2009 at 03:33:57PM +0000, Sitaram Chamarty wrote:

quoted

We also plan to do it in this way, just a small wondering that it
looks a kind of workaround instead of a more graceful solution.

I wouldn't consider it a workaround.  It uses normal Unix
permissions the way they were designed to, including setgid
for directories.

Yes, I think core.sharedrepository is the "official" way to do this, so
it is definitely not a workaround.

Actually, I am yet to come up with a situation where I
actually needed ACLs, though they are more generalised, and
fine-grained.

I like ACLs mainly because you don't have to bug root to change
permissions (like you do to get them to create or modify a group).

-Peff

On 2009-01-07, Boyd Stephen Smith Jr. [off-list ref] wrote:

On Wednesday 2009 January 07 04:55:56 you wrote:

quoted

So when you say "group", you're saying "0660", and when you
say "0660", you're overriding users umask value.

it could just have been the version of git I was using (1.4.4.4, IIRC) --=20
still using that in at least one place, as it is the current version in=20
Debian Etch.

1.4.4.4 is 2 years and 2 days old today!  [I've heard
stories about Debian, but never thought it was this
conservative!]

and I think this was fixed in 06cbe85, last April.