Re: [PATCH v3] am: Allow passing --no-verify flag

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3435 bytes --]

On Mon, Nov 28, 2022 at 06:07:38PM -0500, Taylor Blau wrote:
> Hi Thierry,
> 
> This is looking pretty good. Thanks for pushing out a couple of new
> rounds. I took a look at the discussion and have some thoughts below,
> but they are minor.
> 
> This will likely not be in the upcoming v2.39.0, since Junio has already
> cut and pushed the first release candidate tag. But you should feel free
> to keep working on it in the meantime and we can revisit it post-2.39.

That's fine. No rush. I've had local workarounds for this for a very
long time, so I can be patient for a little longer. =)

> On Mon, Nov 28, 2022 at 06:48:25PM +0100, Thierry Reding wrote:
> > diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
> > index 326276e51ce5..0c1dfb3c98b4 100644
> > --- a/Documentation/git-am.txt
> > +++ b/Documentation/git-am.txt
> > @@ -9,7 +9,7 @@ git-am - Apply a series of patches from a mailbox
> >  SYNOPSIS
> >  --------
> >  [verse]
> > -'git am' [--signoff] [--keep] [--[no-]keep-cr] [--[no-]utf8]
> > +'git am' [--signoff] [--keep] [--[no-]keep-cr] [--[no-]utf8] [--no-verify]
> 
> Spelling this as "[--no-verify]" and not "[--[no-]verify]" is right,
> since the option itself is called "--no-verify" (and thus has the
> OPT_NONEG flag bit set), and "--verify" does not exist. Good.
> 
> >  	 [--[no-]3way] [--interactive] [--committer-date-is-author-date]
> >  	 [--ignore-date] [--ignore-space-change | --ignore-whitespace]
> >  	 [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
> > @@ -138,6 +138,12 @@ include::rerere-options.txt[]
> >  --interactive::
> >  	Run interactively.
> >
> > +-n::
> > +--no-verify::
> > +	By default, the pre-applypatch and applypatch-msg hooks are run.
> > +	When any of `--no-verify` or `-n` is given, these are bypassed.
> 
> Should we be more explicit here, given the discussion in the earlier
> rounds? IOW, instead of saying that they are "bypassed" (which might
> lead the reader to believe that they are run and their output/exit code
> ignored), should we say that they are "not run" and be clearer?

I adopted the wording as for git commit and since the behavior is
exactly the same, it seemed best to stay consistent with that. My
interpretation of "bypassed" is equivalent to "unused" or "ignored",
though "ignored" in this case relating to their existence rather than
return value.

Either wording is fine with me, so if you feel strongly I can reword
this. In that case it might be worth updating the git commit
documentation as well to avoid the same ambiguity.

> 
> The (elided) implementation below looks good to me.
> 
> > diff --git a/t/t4150-am.sh b/t/t4150-am.sh
> > index cdad4b688078..84e6bebeca7a 100755
> > --- a/t/t4150-am.sh
> > +++ b/t/t4150-am.sh
> > @@ -345,6 +345,16 @@ test_expect_success 'am with failing applypatch-msg hook' '
> >  	test_cmp_rev first HEAD
> >  '
> >
> > +test_expect_success 'am with failing applypatch-msg hook (no verify)' '
> > +	rm -fr .git/rebase-apply &&
> > +	git reset --hard &&
> > +	git checkout first &&
> > +	test_hook applypatch-msg <<-\EOF &&
> > +	exit 1
> > +	EOF
> > +	git am --no-verify patch1
> 
> Should we verify that the patch was applied with the expected message?

Yes, that's a good point. I've updated both tests to check that the
patch has been applied and the scripts haven't been run.

Thanks,
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]