Comment 2 for bug 102747

I also concur with you that pre-commit should preferably only reports a list of modified or added files or directories to the plugin. If needed, the plugin could request a whole tree in a temporary area.

There are a few issues though.

o If a branch is large enough, each time a whole tree is requested, there will be space wastage.
o If a list of plugins is specified and each of them requests a tree for itself, do we share a same tree, or create separate trees?

It might be a solution if we create a new branch in a temp directory, apply the merge, then give it back to the plugin. When the plugin finishes using the tree, it must release it (a refcount will tell if the branch has been released). At this time, the tree is reverted, the commiting merge is re-applied, and the tree is given to the next plugin in line.

This solution can also save us some space and time because we only need one temporary space, and a pull will keep it up-to-date with the current tree.

As to the question whether a plugin can modify the tree in pre-commit hook, I think it is free to do whatever it requires but the tree will be discarded (reverted) when it is released back from the plugin. Now, this is another problem because if the plugin intentionally makes conflicting changes, and commits to that, we won't be able to do a pull on that tree to keep it updated anymore (or do we?). What if the plugin deletes the whole temporary tree? In these cases (a pull fails, or the pre-commit tree is gone), we have to create it again.