Junio C Hamano, Wed, Oct 27, 2021 22:16:35 +0200: > Alex Riesen <alexander.riesen@xxxxxxxxxxx> writes: > > > From: Alex Riesen <raa.lkml@xxxxxxxxx> > > > > 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@xxxxxxxxx> > > > > --- > > > > 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.
