I would say that step 1 is to have a "pre-commit" hook as part of the Branch.hooks. Which will be called after we have figured out everything that we need, but before the Branch.last_revision() has been updated.
This ensures that you have a stable view of the tree.
What would also be nice is if the pre-commit hook takes the list of changes that commit worked out. This way, if you want to do something like "do all modified files have only spaces and no tabs", you can do that without having to look at the full tree. (Also works for checking line endings, etc)
At that point, the plugin/hook itself can decide whether it wants to build a complete tree in a temporary area, and run something like 'make check' there.
I would make sure we have enough helpers to make that easy for a plugin (something like bzrlib.transform.build_tree). But I wouldn't expect the pre-commit hook to do it by itself.
Though, I could also see if you had multiple pre-commit hooks that wanted to work on a pristine tree, then you would want a way they could share it, so you don't have problems.
Note, that if you put the hook at this place, you cannot modify the tree in the pre-commit hook. All you can do is ensure that the tree is 'correct'.
An alternative "pre-pre-commit" hook would be invoked (perhaps before any data gathering?). But that can also be easily done in a plugin by installing its own 'cmd_commit'. So I'm not sure we need a pre-pre-commit hook.
I would say that step 1 is to have a "pre-commit" hook as part of the Branch.hooks. Which will be called after we have figured out everything that we need, but before the Branch. last_revision( ) has been updated.
This ensures that you have a stable view of the tree.
What would also be nice is if the pre-commit hook takes the list of changes that commit worked out. This way, if you want to do something like "do all modified files have only spaces and no tabs", you can do that without having to look at the full tree. (Also works for checking line endings, etc)
At that point, the plugin/hook itself can decide whether it wants to build a complete tree in a temporary area, and run something like 'make check' there. transform. build_tree) . But I wouldn't expect the pre-commit hook to do it by itself.
I would make sure we have enough helpers to make that easy for a plugin (something like bzrlib.
Though, I could also see if you had multiple pre-commit hooks that wanted to work on a pristine tree, then you would want a way they could share it, so you don't have problems.
Note, that if you put the hook at this place, you cannot modify the tree in the pre-commit hook. All you can do is ensure that the tree is 'correct'.
An alternative "pre-pre-commit" hook would be invoked (perhaps before any data gathering?). But that can also be easily done in a plugin by installing its own 'cmd_commit'. So I'm not sure we need a pre-pre-commit hook.