Re: [PATCH] Remove negation from the merge option "--no-verify"

From: Alex Riesen <alexander.riesen@cetitec.com>
Date: Oct 28, 2021, 06:38 UTC
Message-ID: <YXpFTJTo0pKhM7xG@pflmari>
In-Reply-To: <xmqq4k92w7do.fsf@gitster.g>

Junio C Hamano, Wed, Oct 27, 2021 22:16:35 +0200:

Show 16 quoted lines

> Alex Riesen <alexander.riesen@cetitec.com> writes:
> 
> > From: Alex Riesen <raa.lkml@gmail.com>
> >
> > This allows re-enabling hooks disabled by an earlier "--no-verify"
> > in command-line and makes the interface more consistent.
> >
> > Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> >
> > ---
> >
> > This one is on top of "[PATCH] Fix "commit-msg" hook unexpectedly called for
> > "git pull --no-verify" (http://public-inbox.org/git/YXfwanz3MynCLDmn@pflmari/).
> > Which is a bit awkward. Should I resend as series?
> 
> Don't we need to do this at the root cause command "git commit"?

The commit preparing code in builtin/merge.c does not seem to use the code from builtin/commit.c, so it does not look like a direct cause of that effect in "git merge". But...

> It is documented to take "--no-verify" but not "--verify" to countermand an
> earlier "--no-verify" on the command line.

This particular peculiarity in implementation of "--[no-]verify" does look like it has root-caused everything :)

> And yes, I agree that we shouldn't introduce an awkwardness in one
> step of the series and fix it in another step of the same series.

I think I better resend everything as a single patch then.