Re: [lmi] Sharing git repositories

[Greg Chicares]

On 2020-03-04 00:39, Vadim Zeitlin wrote:
> On Wed, 4 Mar 2020 00:17:06 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> Then I discovered
> GC>   git config --global core.sharedrepository true
> GC> which seems like a great idea...but is it?
> 
>  It definitely should be used for shared _bare_ repositories. This option
> doesn't affect the working copy files.

Okay, then how exactly do I use it? Here's a post that seems thoughtful:

https://stackoverflow.com/questions/3242282/how-to-configure-an-existing-git-repo-to-be-shared-by-a-unix-group/29646155#29646155

  cd <repo.git>/                            # Enter inside the git repo
  git config core.sharedRepository group    # Update the git's config

Consider our proprietary repository of product data:
  /opt/lmi/blessed/proprietary[0]$git rev-parse --is-bare-repository
  true
There's no corresponding online quasi-central repository: Kim and I
maintain our own "blessed" bare repositories, work with cloned
working copies, exchange git bundles in email, and at certain agreed
moments, we both push to "blessed" and share the resulting SHA1.

AIUI, config keys aren't pushable (and I doubt we'd want to put a
configuration file in the normal repository and share it, because
that represents inconvenient extra work), so we would both have to
make the above change locally, in every "blessed" repository we
have (e.g., in every chroot). But once we've done that, the config
key is part of the bare repository, and would carry forward into
every future copy.

The author continues:

  chgrp -R <group-name> .                   # Change files and directories' 
group
  chmod -R g+w .                            # Change permissions
  chmod g-w objects/pack/*                  # Git pack files should be immutable
  find -type d -exec chmod g+s {} +         # New files get directory's group id

To do that, we'd need to choose exactly one group name and use it
everywhere. But we do have permission to create new groups on our
server, which now has an "lmi" group, and to add ourselves to that
group (though we aren't allowed to make that our "primary" group,
which must remain something like "all_users_of_this_server").

We'd have to add an "lmi" group on our personal machines--in
cygwin, and in debian chroots--but that sounds easy. However, is
it actually the GID that matters, as opposed to the group name?

BTW, all the files in .git/objects/pack/ have "-r--r--r--"
permissions, so...who can write them? I guess git writes them
once only, and never changes them or lets anyone else change
them, right? Does every pack file live forever, or does git
ever erase them (presumably by chmod'ing them first)?

I suppose the changes made by those commands would be commitable
and pushable, so only one person would need to make them, and
then they could be shared in a bundle.

I think I understand the four chgrp and chmod commands above.
But what does
  git config core.sharedRepository group
do that those four commands don't already do?

The author suggests an almost-identical series of commands
for non-bare repositories, specifically including
  git config core.sharedRepository group
Were you implicitly advising against that above:
>  It definitely should be used for shared _bare_ repositories.
or were you just emphasizing the "bare" case?

I think all our non-bare repositories are created by running
some command like git-clone, and I could handle each OAOO thus:
  s/git clone/git clone --config core.sharedRepository=true/
or so I imagine. Would that alone be sufficient, so that the
chmod commands above would be unnecessary?

A different article
  
https://serverfault.com/questions/26954/how-do-i-share-a-git-repository-with-multiple-users-on-a-machine/27040#27040
suggests only
  chgrp -R <whatever group> gitrepo
  chmod -R g+swX gitrepo
(omitting core.sharedRepository). Studying those commands makes
me wonder if there should be a capital 'X' in the other article's
commands, e.g.
-  chmod -R g+w .                            # Change permissions
+  chmod -R g+wX .                           # Change permissions
And I'm worried that this second article's author says
| Then change the umask for the users to 002, so that
| new files get created with group-writable permissions.
just when I had thought that 022 would be perfect. I've read the
"core.sharedRepository" paragraph here
  https://git-scm.com/docs/git-config
several times and still can't understand whether to prefer
  umask 002 ; git config core.sharedRepository group
or
  umask 022 ; git config core.sharedRepository 664

The only thing I know for sure is that I don't want to use ACLs
as the second author advocates.