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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
