Commit c1a4278e switched the "merging checkout" implementation
from 3-way read-tree to merge-recursive, but forgot that
merge-recursive will signal an unmerged state with its own exit
status code. This prevented the clean-up phase (paths cleanly
merged should not be updated in the index) from running.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows "git checkout -m <other-branch>" to notice renames and
carry local changes in the working tree forward.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I've seen some users get into situtations where their HEAD
symbolic-ref is pointing at a non-existant ref. (Sometimes this
happens during clone when the remote repository lacks a 'master'
branch.) If this happens the user is unable to use git-checkout
to switch branches as there is no prior commit to merge from.
So instead of giving the user low-level errors about how HEAD
can't be resolved and how not a single revision was given change
the type of checkout to be a force and go through with the user's
request anyway.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we updated "read-tree -m -u" to be careful about not
removing untracked working tree files, we broke "checkout -m" to
switch between branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
