Stop merging if you need to cherry-pick https://blogs.msdn.microsoft.com/oldnewthing/20180709-00/?p=...
If you need to move a fix into multiple branches, isolate that fix in its own branch to begin with. The entire branch is the cherry. Each target branch deserves its own merge because chances are, seeing as the thing is so critical, the merge needs adequate attention each time to get done correctly (causing more work and friction is sometimes healthy).
If you're reaching the end of your sprint and your branch isn't ready to merge, chances are the entire branch could use another sprint in the oven. You've completely run out of time and you want to isolate a few changes, that's great if you want to move fast and break things.
In TFVC (and SVN, CVS, Perforce, etc.), branches are expensive. It has taken me months to "unteach" people at work antipatterns that arise due to that. Management still doesn't get it - there is this holdout perspective that branches have to be micromanaged. This was the only sensible way to manage the mess caused by TFVC+co.
If you're finding unusual degrees of friction with Git (Mercurial, Bitkeeper, etc.), chances are that you're artificially introducing issues caused by your legacy version control and trying to solve them. Start forgetting and unlearning.
http://svnbook.red-bean.com/en/1.8/svn.branchmerge.using.htm...
Apart from sarcasm, SVN branches use suffer-on-merge: creating a branch means immediate technical debt of the most useless kind, which is more expensive than any inefficient file copying.
From the same manual:
"To perform a sync merge, first make sure your working copy of the branch is “clean”—that it has no local modifications reported by svn status."
"One special kind of flexibility is the ability to have a working copy containing files and directories with a mix of different working revision numbers. Subversion working copies do not always correspond to any single revision in the repository; they may contain files from several different revisions."
If me and Jim are working on two features on the same release and then I find that I need to integrate Jim's work in order to continue mine, Jim will need to merge his [incomplete] work into a common ancestor. If I am working on a feature in a completely different release, this "merge path" gets long and begins to cost money and carry risk. Jim hasn't finished his work yet; before any release can happen, Jim has to finish his work and merge the complete changes to all affected branches. If we can't wait for him to finish, then we're rolling back his changes and, oops, someone rolled back the same change on multiple branches.
Now we can't launch a hundred features because there was an interdependency between two.