Here is where you justify why applying this patch is a good idea for the project and its users. You left it blank. > Signed-off-by: Azat Khuzhin <a3at.mail@xxxxxxxxx> > --- > builtin/pull.c | 6 ++++++ > t/t7503-pre-commit-and-pre-merge-commit-hooks.sh | 12 ++++++++++++ > 2 files changed, 18 insertions(+) I can sort of see the convenience value of doing: $ git pull --no-verify when the remote is *known* to always have problematic changes that you'd rather prefer to skip the check, instead of having to do $ git pull $ git merge --no-verify FETCH_HEAD to see if this time their new stuff passes the check and use the option only when they are unclean. But I am not sure if it is a good idea to let the convenience trump the code hygiene in general. In any case, even if we assume that the convenience value outweighs the downside of allowing people to become even more sloppy, we would need an update to the documentation, no? Would "--no-verify" work well both in the rebase mode and in the merge mode, by the way? If yes, then that would be great. If it works only with one backend but not with the other, do we silently ignore, or do we detect incompatible options and error out? That needs to be designed, documented, and tested, too. Thanks.
