Re: [lmi] git: committing content and mode changes together

[Greg Chicares]

On 2016-11-04 15:30, Vadim Zeitlin wrote:
> On Fri, 4 Nov 2016 14:33:00 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I hesitate to set this:
> GC>   git config core.filemode true
> GC> because, if that's set, then changing a file's mode really does require
> GC> 'update-index --chmod', doesn't it?
> 
>  No, "true" is the default

[I meant to write "false", of course.]

> and corresponds to the normal git behaviour and
> doesn't need to be changed on Unix systems. It is, IME, useful to change it
> to "false" when using Cygwin to tell git not to trust the file system
> permissions because, as I said, they're really not to be trusted there as
> soon as you mix Cygwin and native programs which is more or less
> inevitable.
> 
> GC> And I hesitate to suggest setting it
> GC> for msw (cygwin) only because that would make the same command behave
> GC> differently on different systems. Instead, I think the One True Way is
> GC> to install a pre-commit hook that validates the mode of every file.
> 
>  Yes, having either a pre-commit or update (server-side) hook for checking
> for the wrong permissions is definitely useful. I could send you the update
> hook I use for this purpose

You shared it in personal email to me on 2016-03-15T23:39, thanks.

[I was puzzled at first by this line:
  test_coding_rules=$(command -v test_coding_rules)
since it fails for lack of EXEEXT when cross-compiling and especially since
it's difficult to search the web for the 'command' command. This article
  
http://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250
explains it thoroughly (like 'whence', but portable). Obviously you
understand that already; I just wanted to put it in the archives for
my own future reference.]

> if you'd like to configure it for Savannah
> repository.

Do you have a strong preference for the configuration method? Options:

(1) Specify 'core.hooksPath' in 'git config'. The problem is that this
requires git-2.9, which neither Kim nor I yet use.

https://github.com/blog/2188-git-2-9-has-been-released
| You can now specify a custom path for hooks. Git calls hook scripts to allow
| you to implement custom policy or actions when certain events occur. These
| hook scripts are found inside the .git directory of each repository, making
| them a pain to manage if you have a standard set of hooks for all of your
| repositories. Now you can store the hooks in one place and point all of the
| repositories at them with the new core.hooksPath config.

(2) Symlink a hooks directory:

  cd $(git rev-parse --show-toplevel)
  mkdir hooks
  ln --symbolic $(git rev-parse --show-toplevel)/hooks $(git rev-parse 
--show-toplevel)/.git/hooks

Then any script added to (or modified in) the repository gets used.
Then it's easy to transition to (1) when we upgrade to git-2.9 .

(3) Symlink only 'pre-commit' for the time being. Then it's more work
to customize any other hook, so this sounds plainly worse than (2).
I think (2) is the clear winner.

And if you personally want to customize hooks in a different way, all
of these methods still allow that.

Here's my current 'pre-commit' script, just BTW:

#!/bin/sh

# git pre-commit hook

check_concinnity()
{
    output=$( \
        make src_dir=/opt/lmi/src/lmi -f /opt/lmi/src/lmi/GNUmakefile 
check_concinnity \
        2>&1 | sed \
          -e'/^make[[]/d' \
          -e'/^  Problems detected by xmllint:$/d' \
          -e'/^  Miscellaneous problems:$/d' \
          -e'/^ *[1-9][0-9]* \(source files\|source lines\|marked defects\)$/d'
      )
    if [ -n "$output" ]; then
        printf '%s\n' "$output"
        printf "COMMIT ABORTED\n"
        exit 1
    fi
}

check_concinnity