A lot of times the reason to switch branches is because the user
starts to make a trivial change in the worktree and realizes
that the change belongs to another branch. Other times it is
done by mistake and making it easier to notice that mistake is a
laudable goal.
Your patch allows -m to override this, but that destroys one
very useful feature of -m. In the above "ah, this trivial thing
belongs to the other branch, so let's switch to the branch to
commit only that trivial piece and come back to the current
branch to continue what I'm doing" workflow, I usually first say
"git checkout" without -m to switch, and if it does not allow me
to switch, it is an indication that "the trivial thing" I
thought was trivial was not trivial. I take it as a cue that I
should instead do it "the right way" (i.e. finish or stash away
what I am doing, switch to the branch in a clean state and fix
it properly).
Other times, when all (or most of) the changes in the work tree
logically should have started on a different branch, I do force
it with -m (and take the conflict markers in my worktree), but
being able to forbid the worktree merge by not giving -m is
important.
People with this new configuration set and has to override it
with a command line switch will lose this ability if you
overload that on '-m'.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
