Re: Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3

Bruce Stephens [off-list ref] writes:

Michael J Gruber [off-list ref] writes:

[...]

quoted

Bisecting gives:


5521883490e85f4d973141972cf16f89a79f1979 is first bad commit
commit 5521883490e85f4d973141972cf16f89a79f1979
Author: Junio C Hamano [off-list ref]
Date:   Sun Sep 7 19:49:25 2008 -0700

    checkout: do not lose staged removal

I got the same, which is reassuring.

Looks like a deliberate change with (what seems to me to be) an
unfortunate interaction with "git clone -n"

Yeah, it was meant to allow:

	git clone -n $there $here
        cd $here
        git checkout

and was not taking care of the case to switch branches when the initial
checkout is made.

Perhaps this would help.

 builtin-checkout.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git c/builtin-checkout.c w/builtin-checkout.c
index 05eee4e..d2265df 100644
--- c/builtin-checkout.c
+++ w/builtin-checkout.c

@@ -269,8 +269,7 @@ static int merge_working_tree(struct checkout_opts *opts,
 		}
 
 		/* 2-way merge to the new branch */
-		topts.initial_checkout = (!active_nr &&
-					  (old->commit == new->commit));
+		topts.initial_checkout = !active_nr;
 		topts.update = 1;
 		topts.merge = 1;
 		topts.gently = opts->merge;