Jeff King <peff@xxxxxxxx> writes: > OK, so we failed to pass through --no-verify, because it got caught as a > prefix of --verify-signatures, since the outer parse-options didn't know > about it. Makes sense, and I suppose this has been broken since > 11b6d17801 (pull: pass git-merge's options to git-merge, 2015-06-14). > > I was going to ask whether this should be passing through "verify", and > allowing its "no-" variant, but there is no "--verify" in git-merge. > Arguably there should be (for consistency and to countermand an earlier > --no-verify), but that is outside the scope of your fix (sadly if > somebody does change that, they'll have to remember to touch this spot, > too, but I don't think it can be helped). We do not even have "--verify" in "git commit", because letting the hooks to interfere is the default, but if we were designing it today, we probably would add "--verify" to override a "--no-verify" earlier on the command line, so it is not implausible that people would want to add "--verify" to "git commit" and "git merge" in the future. We can add two hunks, one for builtin/merge.c and another for builtin/pull.c, to leave a note for future developers and it would help quite a lot, I would presume. Thanks.
