From: Ben Knoble <ben.knoble@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Chandra Kethi-Reddy via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Chandra Kethi-Reddy <chandrakr@pm.me>
Subject: Re: [PATCH v3] add: support pre-add hook
Date: Wed, 4 Mar 2026 04:49:47 -0500 [thread overview]
Message-ID: <33EBA399-2D24-48C7-AA1B-EBADF5E520D4@gmail.com> (raw)
In-Reply-To: <xmqqy0k8a4xo.fsf@gitster.g>
> Le 3 mars 2026 à 18:06, Junio C Hamano <gitster@pobox.com> a écrit :
>
> "Chandra Kethi-Reddy via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
>> "git add" has no hook that lets users inspect what is about to be
>> staged. Users who want to reject certain paths or content must
>> wrap the command in a shell alias or wait for pre-commit, which
>> fires too late to prevent staging.
>
> I do not think the above would convince readers that "preventing to
> add" is a worthy goal in the first place. If you "git add foo" by
> mistake and wish you had this hook to prevent 'foo' from getting
> added ever, you can easily "git reset foo" to undo it.
It’s also not clear to me how the proposed hook could inspect “git add A B” and reject A but permit B, but maybe that’s a non-goals.
>> diff --git a/Documentation/githooks.adoc b/Documentation/githooks.adoc
>> index 056553788d..657e14d306 100644
>> --- a/Documentation/githooks.adoc
>> +++ b/Documentation/githooks.adoc
>> @@ -94,6 +94,36 @@ and is invoked after the patch is applied and a commit is made.
>> This hook is meant primarily for notification, and cannot affect
>> the outcome of `git am`.
>>
>> +pre-add
>> +~~~~~~~
>> +
>> +This hook is invoked by linkgit:git-add[1], and can be bypassed with the
>> +`--no-verify` option. It is not invoked for `--interactive`, `--patch`,
>> +`--edit`, or `--dry-run`.
>> +
>> +It takes two parameters: the path to the index file for this invocation
>
> Elsewhere you called these two files "arguments" but here you say
> "parameters". Let's be consistent.
>
>> +of `git add`, and the path to the lockfile containing the proposed
>> +index after staging. It does not read from standard input. If no index
>> +exists yet, the first parameter names a path that does not exist and
>> +should be treated as an empty index.
Saying “it [the hook] does not read from standard in” feels proscriptive rather than descriptive. Why couldn’t I write a short script that asked for confirmation of the paths being added via stdin?
Or perhaps we mean that Git does not write anything to the hook’s stdin… at which point I wonder if Junio’s “let’s not mention that we don’t do this unusual thing” applies? I haven’t looked at how the rest of our documentation describes hooks that aren’t fed input via stdin.
next prev parent reply other threads:[~2026-03-04 9:50 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-10 15:32 [PATCH] add: support pre-add hook Chandra Kethi-Reddy via GitGitGadget
2026-02-10 18:16 ` Junio C Hamano
2026-02-10 19:00 ` Junio C Hamano
2026-02-11 15:16 ` [PATCH] " Chandra
2026-02-11 15:05 ` [PATCH v2] " Chandra Kethi-Reddy via GitGitGadget
2026-02-11 19:50 ` Junio C Hamano
2026-02-11 21:11 ` Chandra
2026-02-11 21:24 ` Junio C Hamano
2026-02-11 21:54 ` Chandra
2026-02-25 2:15 ` [PATCH v3] " Chandra
2026-02-27 5:54 ` Chandra Kethi-Reddy via GitGitGadget
2026-03-03 23:06 ` Junio C Hamano
2026-03-04 9:49 ` Ben Knoble [this message]
2026-03-05 10:47 ` Phillip Wood
2026-03-05 11:40 ` [PATCH v4] " Chandra
2026-03-05 14:48 ` [PATCH v3] " Junio C Hamano
2026-03-05 11:36 ` [PATCH v4] " Chandra Kethi-Reddy via GitGitGadget
2026-03-05 12:03 ` Adrian Ratiu
2026-03-05 12:37 ` Chandra
2026-03-05 12:37 ` [PATCH v5] " Chandra Kethi-Reddy via GitGitGadget
2026-03-05 13:41 ` Adrian Ratiu
2026-03-05 13:46 ` Chandra
2026-03-05 19:23 ` Junio C Hamano
2026-03-06 2:20 ` Chandra
2026-03-13 14:39 ` Phillip Wood
2026-03-05 14:37 ` Phillip Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=33EBA399-2D24-48C7-AA1B-EBADF5E520D4@gmail.com \
--to=ben.knoble@gmail.com \
--cc=chandrakr@pm.me \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.