Re: [lmi] Sharing git repositories

[Vadim Zeitlin]

On Wed, 4 Mar 2020 00:17:06 +0000 Greg Chicares <address@hidden> wrote:

GC> We've copied wx, wxPdfDoc, and proprietary repositories from a single-user
GC> msw machine to a redhat server that's intended to support multiple users,
GC> where umask was 077; and as the saying goes, "hilarity ensued".
GC> 
GC> Whether because of the msw provenance or that awful umask, contents of
GC> the repositories I copied were inaccessible to Kim, or vice versa.

 I'm really not sure how did this happen. It's probably too late for this
now, but my advice would be to either use tar or rsync when copying between
the machines to preserve all the attributes.

GC> It seemed like a good idea to do 'chmod -R 664 *',

 I shuddered a bit while reading this because this reminded me about my own
bad experiences with similar commands. I'm not 100% sure, but I strongly
believe that using chmod with a fixed mode is never a good idea. Using it
with "g+w" or "g+rx" or even "o-rx" may be useful, but not setting the mode
unconditionally.

GC> because some regular files in the repository really are meant to be
GC> executable. I considered trying 'git checkout .', which would probably
GC> have worked, but 'git diff' said:
GC> 
GC> /srv/cache_for_lmi/vcs/wxWidgets[0]$git diff |head -10
GC> diff --git a/3rdparty/catch b/3rdparty/catch
GC> --- a/3rdparty/catch
GC> +++ b/3rdparty/catch
GC> @@ -1 +1 @@
GC> -Subproject commit 011f6e6458d888246f94643e293f002073cff489
GC> +Subproject commit 011f6e6458d888246f94643e293f002073cff489-dirty
GC> diff --git a/autogen.sh b/autogen.sh
GC> old mode 100755
GC> new mode 100644
GC> 
GC> and so on, and I'd never heard of a "dirty" submodule before, so I
GC> didn't try that.

 Dirty submodule just means that the repository is modified, so it can be
fixed by going into the submodule (i.e. "cd 3rdparty/catch") and getting
rid of the changes. In this case you could probably have used the dangerous
(because it IRRETRIEVABLY loses all changes in the working directory!)
"git reset --hard" command to make everything pristine again.

GC> What's the right way to do this? I initially recoiled from "chmod +X"
GC> with a capital X,

 I don't think this one is especially dangerous, but it doesn't seem very
useful neither, i.e. it wouldn't help with making autogen.sh from above
executable again, would it?

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.

GC> Anyway, I decided to use the brutalist approach: raze everything,
GC> thereby testing the code that is intended to reclone repositories
GC> that haven't been cached. If that works

 It probably will, it's just inefficient and I'm, of course, the kind of a
person capable of spending 2 hours optimizing things to avoid a 1 hour
delay. In this particular case optimizing them is not too hard though, as
you could have just cloned from your (as in belonging to the user "greg")
presumably still existing repositories instead of cloning from the remote
ones. The end result should be the same, but it could be achieved much
faster.

 Regards,
VZ

pgpoi8DHFkhn_.pgp
Description: PGP signature