bug during checkout of remote branch and uncommited changes ?

Hi,

Lately I've been caught several time with a problem which, to me, is a bug. It can easily be reproduced, so I think It's very possible it has already been reported.

The problem arise when trying to checkout a branch while having
some uncommited changes. The scenario is the following:
	$ git status
	M  afile.c
	$ git remote add <aremote> <anurl> 
	$ git fetch <aremote> <abranch>
	remote: Counting objects: 7, done.
	remote: Compressing objects: 100% (6/6), done.
	remote: Total 7 (delta 5), reused 3 (delta 1)
	Unpacking objects: 100% (7/7), done.
	From <anurl>
	 * branch                <abranch> -> FETCH_HEAD
	 * [new branch]          <abranch> -> <aremote>/<abranch>
	$ git co <abranch>
	error: Your local changes to the following files would be overwritten by checkout:
		afile.c
	Please commit your changes or stash them before you switch branches.
	Aborting
	$ git reset --hard
	patching file afile.c
	$ git co <abranch>
	fatal: Not tracking: ambiguous information for ref refs/remotes/<aremote>/<abranch>

What can be ambiguous here?
Strangely, trying a second time, succeed:
	$ git co <abranch>
	Previous HEAD position was ...
	Switched to branch '<abranch>'

-- Luc Van Oostenryck

Luc Van Oostenryck <luc.vanoostenryck@gmail.com> writes:

Is that a message from something? It does not sound like something "git reset --hard" would say.

I think the message "Not tracking" is given when there is a remote other than <aremote> that also has <abranch>. Between the time you got the message and the time you tried to checkout <abranch>, did anything happen to cause the second attempt succeed?

On Fri, Jul 07, 2017 at 08:53:39AM -0700, Junio C Hamano wrote:

Indeed, sorry. This is the result of a 'git diff | patch -p1 -R' to
which I'm used since a long time ago. I have no more reason to use
it but ... habits ... :)
 
But doing 'git reset --hard' gives exactly the same result.

Mmmm, no I don't have that.
At this point there is (in .git):
	refs/remotes/<aremote>/<abranch>
	refs/heads/<abranch>
The second one didn't existed before the checkout attempt, of course.
	

No. At least here, the scenario I gave allow to fully reproduce the problem.

Would you like any other information?

-- Luc

Luc Van Oostenryck <luc.vanoostenryck@gmail.com> writes:

Not really.  Here is what I locally ran and its output

-- >8 -- cut here -- >8 --

#!/bin/sh

mkdir -p /var/tmp/x/lvo && cd /var/tmp/x/lvo || exit

rm -fr src dst

(
	mkdir src &&
	cd src &&
	git init &&
	>file &&
	git add file &&
	git commit -m 'initial' &&
	git checkout -b abranch &&
	echo abranch >file &&
	git commit -a -m 'abranch'
) || exit

mkdir dst && cd dst && git init && git pull ../src master && echo mine >file && git status -suno && git remote add aremote ../src && git fetch aremote abranch || exit

git checkout abranch

git reset --hard

git checkout abranch

-- 8< -- cut here -- 8< --

$ sh script
Initialized empty Git repository in /var/tmp/x/lvo/src/.git/
[master (root-commit) 8535bd5] initial
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file
Switched to a new branch 'abranch'
[abranch 32814d9] abranch
 1 file changed, 1 insertion(+)
Initialized empty Git repository in /var/tmp/x/lvo/dst/.git/
From ../src
 * branch            master     -> FETCH_HEAD
 M file
From ../src
 * branch            abranch    -> FETCH_HEAD
 * [new branch]      abranch    -> aremote/abranch
error: Your local changes to the following files would be overwritten by checkout:
	file
Please commit your changes or stash them before you switch branches.
Aborting
HEAD is now at 8535bd5 initial
Switched to a new branch 'abranch'
Branch abranch set up to track remote branch abranch from aremote.

----------------------------------------

As far as I can see, everything is working as intended. The first "git checkout abranch" stops due to the dirty local state before it even tries to DWIM to create abranch, and then after resetting to get rid of all the local modifications, the second "git checkout abranch" manages to create the branch just fine.

Even with different variations (like making dst a clone of src to force the "checkout" to see an ambiguity), I do not seem to get your "the first one fails with an error message about Ambiguity, the second does not", which indeed is a curious symptom.

Without knowing if this is an ancient Git, or what remote other than aremote this repository has, what remote-tracking branches from these remotes this repository has, if they share the same name abranch that points at the same or different objects, etc., I simply do not know what is causing you the symptom, and time I allocated to look into this for now just ran out.

On Fri, Jul 7, 2017 at 11:22 PM, Junio C Hamano <gitster@pobox.com> wrote:

Strange. I forgot to say that I was using git 2.13.0

I have a few more remote but 'abranch' was just a new branch (with name unique to the remote) with fresh objects.

I'll investigate things more here and report if anything new. Thanks, for your time.

-- Luc