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?
hg 1.6
after a merge, files are marked as unresolved.hg
will not let you commit until you have marked them as resolved (doesn't necessarily mean you actually have to resolve them, but I would assume that's the idea). – Explosion Pills Oct 10 '12 at 13:53hg
actually maintains a list of files that have or have not been flagged as "resolved" (usinghg resolve
). If there are anyU
files on this list, it won't let you commit. – Explosion Pills Oct 10 '12 at 13:57hg resolve
is used specifically for merges with conflicts; see selenic.com/mercurial/hg.1.html#resolve.Note that Mercurial will not let you commit files with unresolved merge conflicts. You must use hg resolve -m ... before you can commit after a conflicting merge.
– Mike Partridge Oct 10 '12 at 14:30