Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > Looking through the history the am based rebase has never run the > post-commit hook as am has its own set of hooks and the scripted > version used commit-tree. > >> But the big question here, is what is correct behavior? Should rebase >> call the post-commit hook, or should it skip it? I haven't any clue >> what the answer to that is. > > It's creating a new commit so I lean towards thinking it should run > the post-commit hook. As an example I have a post-commit hook that The reason why "am" did not run "post-commit" is because "post-commit" was (originally) meant to be for cases where the end user types "git commit", IOW, the notion of "since we are creating a new commit object, let's run the post-commit hook" used to be totally misguided way of thinking. The hook was "the user _ran_ 'commit', so post-commit is run immediately afterwards". These days, I think most of our tools subscribe to the newer "a commit got created--have hook the chance to report it" idea, simply because the original position is untenable---"git merge" may not want to run the post-commit hook according to the initial design, and it is fine to make it not to run it when clean automerge was recorded, but sometimes the end users have to type "git commit" to conclude a conflicted merge. So from that point of view, I do not think it is too bad to bring "am" into the new ear and start running post-commit from it. The "pre-commit" hook is a different story, though. From purely practical point of view, starting to run extra verification that may veto new commits from getting created only because we changed the implementation detail for some reason is a disservice to the users.
