From: Junio C Hamano Date: Wed, 12 Nov 2008 19:15:37 GMT Subject: Re: Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3 Message-ID: <7vprl0oiw6.fsf@gitster.siamese.dyndns.org> In-Reply-To: <80r65gon3m.fsf@tiny.isode.net> Bruce Stephens writes: > Michael J Gruber writes: > > [...] > >> Bisecting gives: >> >> >> 5521883490e85f4d973141972cf16f89a79f1979 is first bad commit >> commit 5521883490e85f4d973141972cf16f89a79f1979 >> Author: Junio C Hamano >> 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;