Configuring a third-party git hook

I have a bit of a weird question. Poking around with Google searches
hasn't come up with any results, so I'm asking here :)

Short version: What's the most appropriate way to configure a git hook?

Long version: I have a git hook (handles prepare-commit-msg and
commit-msg) and part of what it does can search 'git log' for a single
file. It doesn't really care about the full history, and wants to be
reasonably fast (as the user is waiting for it). It's just a
convenience, so correctness isn't a huge issue. The easiest way to
keep it moving through quickly is to limit the search:

$ git log ...other options... HEAD~100 some-file.pike

The problem with this is that it doesn't work if HEAD doesn't have 100
great-great-...-grandparents - plus, it's way too specific a number to
hard-code. I might want it different on different repos (and the
script is shared, and is available for other people to use).

Now, if this were something in git core, I'd expect to set that value
of 100 with 'git config', but this is my own script. Is it right to
use 'git config' for something that isn't controlled by the core code
of git? I've tentatively used "git config rosuav.log-search.limit"
(with 0 or absence meaning "omit the argument" ie search the whole
history), and am wondering if that's a really really bad idea.

Here's the script in question:
https://github.com/Rosuav/shed/blob/master/githook.pike#L36

Two parts to the question, then. Firstly, is it acceptable to use 'git
config' for a hook like this? And secondly, either: Is there a naming
convention to follow? or, what alternative would you recommend?

Thanks in advance for any ideas/tips!

ChrisA

On Wed, Mar 19, 2014 at 12:16 PM, Chris Angelico [off-list ref] wrote:

Two parts to the question, then. Firstly, is it acceptable to use 'git
config' for a hook like this? And secondly, either: Is there a naming
convention to follow? or, what alternative would you recommend?

1. I would say yes. git config is made to be extended and doesn't
require a config item to be known.
2. Namespacing the config items like you did is a good thing to do so
it won't interfere with other options.

On Thu, Mar 20, 2014 at 11:53 PM, Kevin [off-list ref] wrote:

On Wed, Mar 19, 2014 at 12:16 PM, Chris Angelico [off-list ref] wrote:

quoted

Two parts to the question, then. Firstly, is it acceptable to use 'git
config' for a hook like this? And secondly, either: Is there a naming
convention to follow? or, what alternative would you recommend?

1. I would say yes. git config is made to be extended and doesn't
require a config item to be known.
2. Namespacing the config items like you did is a good thing to do so
it won't interfere with other options.

Excellent! Thank you.

Is this documented anywhere? The git config man page says to look to
other git man pages:

https://www.kernel.org/pub/software/scm/git/docs/git-config.html#_variables

A comment there to the effect that "Third party tools may also define
their own variables" or something would make it clear that this is the
intention.

ChrisA

On Fri, Mar 21, 2014 at 03:51:16AM +1100, Chris Angelico wrote:

quoted

1. I would say yes. git config is made to be extended and doesn't
require a config item to be known.
2. Namespacing the config items like you did is a good thing to do so
it won't interfere with other options.

Excellent! Thank you.

Is this documented anywhere? The git config man page says to look to
other git man pages:

https://www.kernel.org/pub/software/scm/git/docs/git-config.html#_variables

A comment there to the effect that "Third party tools may also define
their own variables" or something would make it clear that this is the
intention.

I think this sentence from the section you linked is meant to express
that:

  You will find a description of non-core porcelain configuration
  variables in the respective porcelain documentation.

but it is rather opaque, isn't it? You did not know it, but your hook is
a non-core porcelain. :)

I think it could probably be re-worded, and possibly even indicate to
authors of other programs that they are free to make up their own
variables (but should take care with namespacing them appropriately).

Would you like to try your hand at writing a patch?

-Peff

On Fri, Mar 21, 2014 at 10:38 AM, Jeff King [off-list ref] wrote:

quoted

A comment there to the effect that "Third party tools may also define
their own variables" or something would make it clear that this is the
intention.

I think this sentence from the section you linked is meant to express
that:

  You will find a description of non-core porcelain configuration
  variables in the respective porcelain documentation.

but it is rather opaque, isn't it? You did not know it, but your hook is
a non-core porcelain. :)

I think it could probably be re-worded, and possibly even indicate to
authors of other programs that they are free to make up their own
variables (but should take care with namespacing them appropriately).

Would you like to try your hand at writing a patch?

.... oohhhhhh. Heh. I thought the "porcelain" sections of git were the
lower-level or machine-readable versions of other tools, and didn't
really think of mine as fitting into that.

How does the attached patch look?

ChrisA

On Fri, Mar 21, 2014 at 10:46:15AM +1100, Chris Angelico wrote:

.... oohhhhhh. Heh. I thought the "porcelain" sections of git were the
lower-level or machine-readable versions of other tools, and didn't
really think of mine as fitting into that.

The term sometimes gets used confusingly. The "plumbing" is the
low-level stuff that supports the "porcelain", that users interact with.
But sometimes options to produce low-level scriptable output get called
"--porcelain", as in "this is the output to be used when building a
porcelain on top".

Calling a hook script "porcelain" is kind of stretching it, I think, but
it is filling the same role (it is software built on top of git, and
using git to store config options).

Thanks, the new text looks good to me. Please follow SubmittingPatches
(notably, you need to sign-off your work, and please send patches inline
rather than as attachments).

-Peff

On Fri, Mar 21, 2014 at 2:43 PM, Jeff King [off-list ref] wrote:

Thanks, the new text looks good to me. Please follow SubmittingPatches
(notably, you need to sign-off your work, and please send patches inline
rather than as attachments).

Ah, didn't see that file.

From 6e1fc126ece37c6201d0c16b76c6c87781f7b02b Mon Sep 17 00:00:00 2001

From: Chris Angelico <redacted>
Date: Fri, 21 Mar 2014 10:45:08 +1100
Subject: [PATCH] Explain that third-party tools may create 'git config'
 variables

Signed-off-by: Chris Angelico <redacted>
---
 Documentation/config.txt |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 73c8973..23f0466 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt

@@ -131,8 +131,9 @@ Variables

 Note that this list is non-comprehensive and not necessarily complete.
 For command-specific variables, you will find a more detailed description
-in the appropriate manual page. You will find a description of non-core
-porcelain configuration variables in the respective porcelain documentation.
+in the appropriate manual page. Other git-related tools may define their own
+variables, which will be defined on their respective manual pages; ideally,
+these will be named in some way to indicate the project or creator.

 advice.*::
  These variables control various optional help messages designed to

-- 
1.7.10.4


Made that patch off master, which is currently basically the same as
maint anyway.

ChrisA