Re: [lmi] Sharing git repositories

[Vadim Zeitlin]

On Wed, 4 Mar 2020 22:31:52 +0000 Greg Chicares <address@hidden> wrote:

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

 This depends on what is the actual goal here and I must admit I'm not
totally certain about this. Just to explain my point of view/frame of
reference: typically, Git is used with several repositories. There can be
just about any relationship between them, but it's pretty common to have
some central/shared repository (and quite common to have several such
repositories) and a per-user repository (and maybe several of those too).
In the canonical case, there is a bare shared repository on some server and
different users clone it to create their own user-specific repositories.
Then they can push their changes to the shared repositories and pull the
changes done by the other users (or by themselves on a different machine!).
This is how we use Savannah, of course, and also how we use GitHub: both of
them just use Unix servers hosting (an enormous number of, so I expect it's
a bit different from hosting a few dozens repositories as I do on my own
server) bare Git repositories.

 But I'd really like to know what are you trying to achieve here, i.e. what
would be your desired ideal setup and workflow?

GC> Here's a post that seems thoughtful:
GC> 
GC> 
https://stackoverflow.com/questions/3242282/how-to-configure-an-existing-git-repo-to-be-shared-by-a-unix-group/29646155#29646155

 The post seems correct, but why would you want to configure an _existing_
repository for sharing instead of creating a new one? Normal course of
actions is to just use

        $ git init --bare --shared /path/to/new/repository

and then either fetch the existing repository from it or git-push with
--mirror option into it.

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

 You don't have to do anything like this if you use my command above with
the possible exception of the first one if you want to use a group
different from the default one for the new repository.

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

 No, you don't have to have "lmi" group on your personal machines and
neither group name nor GID matter. This group is only used on the machine
where the bare Git repository resides. When you push to this repository,
you execute Git on the server (via ssh usually, but other transports can
also be used) and this Git process runs as the user you've authenticated
as. As long as this user is a member of the "lmi" group _on_the_server_,
you will have permissions to push to the repository -- and, conversely,
otherwise you won't.

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

 Sorry, I don't really remember the details of pack files management and
I'm not sure if Git ever updates them or always erases the existing packs
and creates new ones (I think it's the latter but I could be wrong). What
matters is that these files must not be modified manually and are indeed
managed exclusively by Git itself.

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

 No, these changes apply only to the bare repository on the server, they
are not part of the repository contents and so can't be neither committed
nor pushed. OTOH it's not necessary to share them anyhow, as you only want
to use these permissions for this particular repository.

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

 If nothing else, it sets the sticky bit to ensure that all the new files
will be created with the correct (i.e. same) group too. It may have other
effects, but I'm not aware of them to be honest.

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

 Yes, the typical use case is to share a bare repository. Non bare
repositories can be shared as well, but this can be confusing and
definitely wastes disk space on the unnecessary working copy, so why would
you do it?

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

 I'm still not sure _what_ should it be sufficient for, but this approach
seems weird to me and generally "Git" and "weird" can result in a lot of
confusion (although sometimes you can do wonderful things too). To repeat
in different words what I wrote above, only a single, ideally bare, Git
repository should be shared. Your personal repositories don't need to set
core.sharedRepository at all.

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

 ACLs can be useful for more complex cases, but our case is (or at least
seems to me) as simple as it gets, so I don't think it's worth considering
them.

 Regards,
VZ

pgpf61UZfDqtC.pgp
Description: PGP signature