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
So why is committing with unresolved files frowned upon/prevented? Is there any reason other than tradition?