[Top][All Lists]

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

Re: commit-msg hook

From: Paul Eggert
Subject: Re: commit-msg hook
Date: Sat, 11 Apr 2015 08:40:29 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

Eli Zaretskii wrote:
the problem with hanging is not due
to Gawk, but instead due to 'printf': it doesn't produce the UTF-8
encoding of the percent sign

OK, so we're dealing with a broken MS-Windows shell rather than a broken MS-Windows gawk. That 'printf' command is there only so that the script can be pure ASCII, and it's simpler to avoid that nicety. I installed the attached patch to try to work around the shell bug.

As regards the idea of using Emacs rather than the shell, I'm with Dmitry: let's not assume Emacs is already working when bootstrapping a new Emacs. Instead, let's merely assume that a new developer has a working shell, since that's needed anyway for other reasons.

Is it possible to install the hooks in GNUMakefile, so that running
autogen.sh manually wouldn't be needed?  I normally almost never run
autogen.sh, I always just run "make" from the top-level directory.

I'm leery of that. GNUMakefile is run by everybody, not just by developers. And there are good reasons that the Git hooks are not themselves in the Git repository (if they were in the repository, and they were sufficiently messed up, then one couldn't 'git commit' fixes). If we routinely updated the Git hooks automatically, we'd make it more likely that Git non-experts would put their painfully constructed repositories into a "broken" state, and we already have too much panic in that neighborhood.

That being said, it might make sense to separate the Git hook (re)initialization into an autogen.sh option, since it's cheap whereas autogen.sh by default is expensive.

Attachment: 0001-Port-commit-msg-to-broken-MS-Windows-shell.patch
Description: Text Data

reply via email to

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