[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Sharing git repositories

From: Greg Chicares
Subject: [lmi] Sharing git repositories
Date: Wed, 4 Mar 2020 00:17:06 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

We've copied wx, wxPdfDoc, and proprietary repositories from a single-user
msw machine to a redhat server that's intended to support multiple users,
where umask was 077; and as the saying goes, "hilarity ensued".

Whether because of the msw provenance or that awful umask, contents of
the repositories I copied were inaccessible to Kim, or vice versa.

It seemed like a good idea to do 'chmod -R 664 *', but that made all
subdirectories inaccessible. Then I tried this:

sudo find /srv/cache_for_lmi/blessed -type f -exec chmod 664 {} \;
sudo find /srv/cache_for_lmi/blessed -type d -exec chmod 775 {} \;

which led to:

./install_wx.sh: 83: /cache_for_lmi/vcs/wxWidgets/config.guess: Permission 

because some regular files in the repository really are meant to be
executable. I considered trying 'git checkout .', which would probably
have worked, but 'git diff' said:

/srv/cache_for_lmi/vcs/wxWidgets[0]$git diff |head -10
diff --git a/3rdparty/catch b/3rdparty/catch
--- a/3rdparty/catch
+++ b/3rdparty/catch
@@ -1 +1 @@
-Subproject commit 011f6e6458d888246f94643e293f002073cff489
+Subproject commit 011f6e6458d888246f94643e293f002073cff489-dirty
diff --git a/autogen.sh b/autogen.sh
old mode 100755
new mode 100644

and so on, and I'd never heard of a "dirty" submodule before, so I
didn't try that.

What's the right way to do this? I initially recoiled from "chmod +X"
with a capital X, because its specification seems to say that it would
transform, say,
which seemed kind of loony. But loony behavior in loony scenarios
might be okay, because in a more normal scenario like
it would lead to
if I understand correctly, and that's kind of loony, but I guess it
would at least do the somewhat right thing. But still it feels weird.

Then I discovered
  git config --global core.sharedrepository true
which seems like a great idea...but is it? With a rational umask
of 022, it seems to make no difference:

/opt/lmi/src[0]$rm -rf /opt/lmi/src/lmi
/opt/lmi/src[0]$git clone https://github.com/vadz/lmi.git 2>&1 |less -S
/opt/lmi/src[0]$ls -l lmi |head -4
total 9476
-rw-r--r--. 1 REDACTED REDACTED    320 Mar  3 18:32 about-16.png
-rw-r--r--. 1 REDACTED REDACTED   4233 Mar  3 18:32 about_dialog.cpp
-rw-r--r--. 1 REDACTED REDACTED   2580 Mar  3 18:32 about_dialog.hpp
/opt/lmi/src[0]$rm -rf /opt/lmi/src/lmi
/opt/lmi/src[0]$git clone --config core.sharedrepository=true 
https://github.com/vadz/lmi.git 2>&1 |less -S
/opt/lmi/src[0]$ls -l lmi |head -4
total 9476
-rw-r--r--. 1 REDACTED REDACTED    320 Mar  3 18:33 about-16.png
-rw-r--r--. 1 REDACTED REDACTED   4233 Mar  3 18:33 about_dialog.cpp
-rw-r--r--. 1 REDACTED REDACTED   2580 Mar  3 18:33 about_dialog.hpp

...so is that git.config key needless when umask is reasonable?

Anyway, I decided to use the brutalist approach: raze everything,
thereby testing the code that is intended to reclone repositories
that haven't been cached. If that works, then next time we'll see
whether the caching works as intended. If so, then I suppose the
real lesson is not to go messing with chmod when you have a script
that recreates the whole lmi universe in an hour.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]