From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Chandra Kethi-Reddy via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, phillip.wood@dunelm.org.uk,
Chandra Kethi-Reddy <chandrakr@pm.me>
Subject: Re: [PATCH v3] add: support pre-add hook
Date: Thu, 05 Mar 2026 06:48:24 -0800 [thread overview]
Message-ID: <87h5qujps7.fsf@gitster.g> (raw)
In-Reply-To: <27ee9a9c-0caa-4b6e-a968-51c71c8b6e5f@gmail.com> (Phillip Wood's message of "Thu, 5 Mar 2026 10:47:27 +0000")
Phillip Wood <phillip.wood123@gmail.com> writes:
> paths that are staged by the current invocation of "git add". That means
> if for some reason I need to bypass the hook when running "git add" I'll
> have to bypass it every time until I commit and cannot check the other
> changes that I'm staging. It also means that running "git add" several
> times, each with a different path runs the hook multiple times on the
> same content.
Correct. You'd need "git diff --name-only HEAD" twice and run the
results through "comm -13" or something.
> These caveats are rather unfortunate as it means to be sure that staged
> changes get checked I have to duplicate the "pre-add" checks in the
> "pre-commit" hook which is rather inefficient. It would be very nice to
> be able to check changes as they're staged rather than just before they
> are committed but I can't help feeling that what's proposed here is
> driven by ease of implementation which leads to a rather incoherent user
> experience.
True.
As I already said, I am not sure of the value of the proposed hook.
Thanks.
next prev parent reply other threads:[~2026-03-05 14:48 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
2026-03-05 10:47 ` Phillip Wood
2026-03-05 11:40 ` [PATCH v4] " Chandra
2026-03-05 14:48 ` Junio C Hamano [this message]
2026-03-05 11:36 ` 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=87h5qujps7.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=chandrakr@pm.me \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
/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.