Why not commit unresolved changes?
- by Explosion Pills
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?
