In a traditional VCS, I can understand why you would not commit unresolved files because you could break the build. However, I don't understand why you shouldn't commit unresolved files in a DVCS (some of them will actually prevent you from committing the files).

Instead, I think that your repository should be locked from pushing and pulling, but not committing.

Being able to commit during the merging process has several advantages (as I see it):

• The actual merge changes are in history.
• If the merge was very large, you could make periodic commits.
• If you made a mistake, it would be much easier to roll back (without having to redo the entire merge).
• The files could remain flagged as unresolved until they were marked as resolved. This would prevent pushing/pulling.

You could also potentially have a set of changesets act as the merge instead of just a single one. This would allow you to still use tools such as git rerere.

So why is committing with unresolved files frowned upon/prevented? Is there any reason other than tradition?