From: Junio C Hamano <gitster@pobox.com>
To: "Chandra Kethi-Reddy via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Chandra Kethi-Reddy <chandrakr@pm.me>
Subject: Re: [PATCH] add: support pre-add hook
Date: Tue, 10 Feb 2026 11:00:50 -0800 [thread overview]
Message-ID: <xmqq8qd0zan1.fsf@gitster.g> (raw)
In-Reply-To: <xmqqldh0zcpa.fsf@gitster.g> (Junio C. Hamano's message of "Tue, 10 Feb 2026 10:16:17 -0800")
Junio C Hamano <gitster@pobox.com> writes:
> The hook takes no clue from anything derived from the command line,
> not even the pathspec (or list of individual paths computed using
> the pathspec by the command) or the mode of operation like '-u' or
> '--renormalize'. I am not sure how effective a decision the invoked
> hook can make to approve or deny in this lack of information.
And I do not necessarily suggest passing the pathspec arguments or
command line options that the "git add" command received from its
caller down to the hook, which will force hook authors to emulate
what "git add" would do to these arguments and options, and they
will certainly get it wrong.
I wonder if we can split write_locked_index() into two so that
writing out the in-core index to the temporary/lockfile can happen
separately from the call to commit_locked_index(). If we can do so,
then the following would become a viable and better implementation
of this new feature to run the "pre-add" hook:
* Determine if we will need to run this "pre-add" hook, at the
location in the code you addded the run_hooks_opt() invocation,
but do *NOT* run any hook there yet.
* Instead, create a temporary copy of the index file if the above
says "Yes, we are going to run the hook".
* Let the code path to update the in-core index, i.e., letting
everythning up to the "finish:" label to run normally.
* Perform the first-half of the write_locked_index(), writing the
new index contents into the lockfile, but stopping before
committing it to the final name.
* If we are running the hook, run it with two arguments, the name
of the temporary copy of the original index we created earlier,
and the name of this lockfile that has the proposed contents of
the index if the hook allowed "git add" to proceed.
* If we ran the hook and hook succeeded, or if we did not have to
run the hook at all, then commit the lockfile. Otherwise abort
the "git add" command and rollback_lock_file().
* Remove the temporary file we created earlier (if any).
Your hooks can "GIT_INDEX_FILE=$1 git diff --cached --name-only" to
find out which paths already had changes added before this
invocation of "git add", and similarly using $2 get the list of
paths that will add further changes with this invocation. The
latter set of paths you can inspect to see if you like the
additional changes brought in, perhaps like
#!/bin/sh
paths=$(GIT_INDEX_FILE=$2 git diff --cached --name-only)
GIT_INDEX_FILE=$1 git diff $paths >patch.txt
if grep "^+.*secret" patch.txt
then
echo "do not divulge company secret!" >&2
exit 1
fi
or something.
next prev parent reply other threads:[~2026-02-10 19:00 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 [this message]
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
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=xmqq8qd0zan1.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=chandrakr@pm.me \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox