The biggest issue that I can see is that it creates a window of commits where things are half-merged and (probably) not working correctly. When you push the final set of local commits, all of those intermediate commits will also apear for everyone else. In ideal world, I should be able to pull any commit and the code should work. If you start committing in the middle of merges, the state of the code isn't well-defined.
One thing you could do is make local commits to your merge, and then bundle them into one big commit when you push (though I'm not sure how(if?) any vcs support this). While this might yield some of the benefits you mentioned, I'm not sure it's worth the extra complexity (we're already dealing with a fairly confusing and complex area).
One of the branching philosophies (section Developing Branching Strategy and Codeline Policy in Advanced SCM Branching Strategies - also read Perforce Best practices, its a pdf but goes into some other details) is that you branch on incompatabile policy.
A codeline policy
specifies the fair use
and permissible check-ins for the codeline,
and is the essential user’s manual for
codeline SCM. For example, the policy of
a development codeline should state that
it isn’t for release; likewise, the policy of a
release codeline should limit changes to
approved bug fixes. The
policy can also describe
how to document changes
being checked in, what
review is needed, what
testing is required, and
the expectations of
codeline stability after
check-ins. A policy is a
critical component for a
documented, enforceable
software development
process, and a codeline
without a policy, from an
SCM point of view, is out of control.
(from Perforce Best Practices)
Say you have the branches 'release' (or 'master') from which a release is built and 'trunk' (or 'dev') where developers check in working code. These are the policies of the branches. Noting the 'working code' is part of the 'dev' branch policy, one should never commit broken code to the dev branch. Often there are things such as CI servers hooked up to these branches and checking in broken code into dev could mess up everyone's branch and break the build.
However, there are times when it is appropriate to check in partial code that doesn't work. In these instances, one should branch - an incompatible policy with trunk. In this new branch, one can decide the policy ('broken code is ok') and then commit code to it.
There is one simple rule to determine if a
codeline should be branched: it should be
branched when its users need different
check-in policies. For example, a product
release group may need a check-in policy
that enforces rigorous testing, whereas a
development team may need a policy that
allows frequent check-ins of partially tested
changes. This policy divergence calls for a
codeline branch. When one development
group doesn’t wish to see another
(from Perforce Best Practices)
Realize that this is coming from a central server based SCM with a strong corporate mindset. The core idea is still good. These are often thought of implicitly - you don't check in untested dev code into the release branch. Thats a policy.
So branch, say that this branch can have broken code and commit away.
Best Answer
Commit a single unit of work. Otherwise reverting the commit or remerging it elsewhere (different branch) will be painful.