Hi, Bertram Scharpf wrote: > today I wrote a port-merge hook. Then I just detected that it only gets > executed when the merge is immediately successful. In case there is a > conflict, I have to finish the merge using the command "git commit". > This will not call the post-merge hook. > > I think the hook should be reliable to be executed on _every_ non-failed > merge. Therefore I propose the below extension. I agree that at first glance this sounds like a good thing. A manual conflict resolution is not so different from a very smart merge strategy, after all. Nits: > Bertram Sign-off? (See Documentation/SubmittingPatches, section 5 "Sign your work" for what this means. > --- a/builtin/commit.c > +++ b/builtin/commit.c > @@ -1783,6 +1783,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix) > > rerere(0); > run_commit_hook(use_editor, get_index_file(), "post-commit", NULL); > + if (whence == FROM_MERGE) > + run_hook_le(NULL, "post-merge", "0", NULL); "git merge" doesn't run the post-commit hook, so there's a new asymmetry being introduced here. Should "git merge" run the post-commit hook? Should a "git commit" that means "git merge --continue" avoid running it? Also if doing this for real, the documentation should be updated and tests introduced to make sure the behavior doesn't get broken in the future. Documentation/githooks.txt currently says This hook cannot affect the outcome of git merge and is not executed if the merge failed due to conflicts. which would need to be updated to say that the hook will run later in that case, when the merge is finally committed. Thanks and hope that helps, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html