Re: [lmi] Proposed workflow for proprietary repository

[Vadim Zeitlin]

On Fri, 10 Nov 2017 17:59:09 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-03-20 19:50, Greg Chicares wrote:
GC> [...]
GC> > Here's how to create a bundle to share by email. Make any number of
GC> > changes to the local repository, and commit them in whatever groups
GC> > make sense:
GC> > 
GC> >   cd /opt/lmi/proprietary
GC> >   git commit --all -m"One set of changes"
GC> >   git commit --all -m"Another set of changes"
GC> > 
GC> > When it's ready to share, do this:
GC> > 
GC> >   cd /opt/lmi/proprietary
GC> >   git bundle create YourBundleName ^origin/master HEAD --branches
                                         ^^^^^^^^^^^^^^^^^^^
 This is off-topic, but I'd just like to note that now that you're aware of
Git "A..B" notation, you could replace this part with "origin/master..HEAD"
which is a bit a more understandable IMHO as closer to the standard
interval notation (except in Git intervals are open-closed semi-intervals).

GC> > (using a more descriptive name) and send the file as an email
GC> > attachment.
GC> 
GC> Vadim--This has worked perfectly until about a month ago. Since then,
GC> every time Kim prepares a bundle, permissions on many files get changed.
GC> Please help us figure out how to prevent this.

 Brief answer is to set core.filemode to false. When I started to use Git
with Cygwin (admittedly, this was a long -- was it really 9 years?? -- time
ago), I experimented with different settings/combinations of file
modes/ACLs and this was the only possibility to make things work reliably.
Maybe things have changed since then, but your experience seems to disprove
this and in any case the one thing I'm sure about is that they still work
fine with core.filemode set to false.

 Additionally, my ~/.gitconfig has this comment:

[core]
        # setting this to false make git status twice faster because
        # ignoreCygwinFSTricks is turned on by default then
        filemode = false

and while, again, things could have changed since then, but this did have a
big effect on Git performance back then and Git documentation still
mentions 2x speedup from it.

GC> Applying a bundle sent yesterday (possibly from a new machine configured
GC> by corporate IT), I see:
GC> 
GC> data/NAME-REDACTED.database          |  4 ++--  [for each of six files]
GC> src/my_db.cpp                        | 12 ++++++------
GC> 
GC> That's six files with four lines changed in each (24) plus one with 12,
GC> for a total of 36, which is the same total as the summary line:
GC> 
GC> 1030 files changed, 18 insertions(+), 18 deletions(-)
GC> 
GC> but there are just over a thousand lines like this:
GC> 
GC> data/sample.database                 |  0
GC> 
GC> and then another thousand or so like this:
GC> 
GC> mode change 100644 => 100755 data/sample.database

 If you really want to debug this, you need to look at MSW ACL for this
file, using cacls or icacls as discussed just recently. Of course, even if
you see that some ACL is unexpectedly set or unset, it won't necessarily
help that much, but we need to start with at least something.

 Also, I'm not completely sure if the file is actually executable on the
machine where "git bundle" was made, could you please confirm whether it is
the case?

GC> [...] yet I'd like to find a way
GC> to prevent such problems from arising. For example, several hundred
GC> of these files are freshly regenerated by msw-native programs (rather
GC> than being migrated from another machine), and it would be helpful to
GC> intercept and reverse permission changes before a git bundle is
GC> created.

 Unfortunately I don't think there are any hooks invoked during git bundle
creation. And, anyhow, detecting the problem at this moment could be too
late to be helpful. So the only solution I see is to indeed ensure that
commit hooks check for this -- and are executed, of course. Maybe you could
print something from the commit hook even if all checks passed successfully
(of course, I advise this, but I'd hate it for the main lmi repository...)
and ask everybody committing to it to check that this message was given.

GC> I hesitate to suggest doing the following (for cygwin only):
GC>   git config core.filemode false
GC> because it seems like a kludge, and data files really shouldn't ever
GC> have the executable bit set.

 Honestly, if this solves the problem -- and I think it ought to -- I'd do
it without a second thought. Yes, core.files is a kludge, but then the
entire concept of Cygwin is a kludge anyhow, so I don't think it's worth
fighting for immaculate purity when using it.

GC> I'm thinking of adding appropriate commands at the beginning of the
GC> pre-commit hook, something like [not quite correct]:
GC>   chmod +R -x+X
GC> in the hope that this will prove inexpensive and perfectly robust.
GC> If that sounds like a good idea, could you help me figure out how
GC> to write the command correctly?
[...]
GC> Maybe use some 'find ... xargs' thing to exclude '*.sh' and '*.sed',
GC> and apply 'chmod -x' to every file not excluded? E.g. [untested]:
GC> 
GC> find . -name '*.sh' -o -name '*.sed' -type f | xargs chmod -x
GC> 
GC> Would that work reliably in a directory with thousands of files?
GC> (I think is should, and that's why we use 'find', but I don't
GC> understand this stuff very well.)

 I guess it's just a typo, but the logic of the command above is reversed:
there should be a -not (or "!" if you want to be POSIX compliant) or two
here and it should be something like this (still untested) instead:

        find . \! -name '*.sh' \! -name '*.sed' -type f | xargs chmod -x

(of course, you can rewrite this "!A & !B" as "!(A | B)" if you prefer, but
this would require quoting even more characters from the shell).

 Other than that the command looks fine to me. Purists would argue that you
should use "find -printf0" and "xargs -0", but as long as you avoid white
space in your file names (which is an excellent idea anyhow), this is not
necessary.

 And I think the idea of making non-executable all but whitelisted files is
a better one than blacklisting some files because if you add another
category of files that should be executable and their executable bit is
reset by this script, it will get noticed much sooner than if you add some
new type of non-executable files and forget to blacklist it.

 Regards,
VZ