"git checkout foo" is getting confused by folder named "foo"
Hi, maybe this has already been reported, but I didn't find it in the mail archive. If I understand correctly, after I clone a repo, I should be able to switch to branch foo just by running git checkout foo This doesn't seem to work if a folder called "foo" exists in the root of the repo. I got the same behavior with git 1.8.3.2 on a Mac and git 1.7.9.5 on Linux. Steps to reproduce: git clone https://github.com/dbpedia/extraction-framework.git cd extraction-framework/ First the happy path - there is a remote branch "live-dev", but no folder "extraction-framework/live-dev": git checkout live-dev Response: Branch live-dev set up to track remote branch live-dev from origin. Switched to a new branch 'live-dev' Fine! Now the unhappy path - there is a branch "wiktionary", but also a folder "extraction-framework/wiktionary": git checkout wiktionary Nothing - no response, no changes to working tree. .git/index seems to be modified though. Slightly different - cd to some folder, try checkout again: cd mappings git checkout wiktionary Response: error: pathspec 'wiktionary' did not match any file(s) known to git. My workaround is that when I switch to a branch for the first time, I have to call git checkout -t -b wiktionary --track origin/wiktionary Response: Branch wiktionary set up to track remote branch wiktionary from origin. Switched to a new branch 'wiktionary' Looks good. After that, I can switch back and forth between branches just by git checkout wiktionary / git checkout master. Cheers, Christopher -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "git checkout foo" is getting confused by folder named "foo"
On 25 September 2013 04:51, David Aguilar wrote: > On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt > wrote: >> Hi, >> >> maybe this has already been reported, but I didn't find it in the mail >> archive. >> >> If I understand correctly, after I clone a repo, I should be able to >> switch to branch foo just by running >> >> git checkout foo >> >> This doesn't seem to work if a folder called "foo" exists in the root >> of the repo. > > git checkout foo -- Thanks for the suggestion, but it doesn't work for me. With both 1.7.9.5 and 1.8.3.2, I get this: $ git checkout wiktionary -- fatal: invalid reference: wiktionary When I try the full branch name: $ git checkout origin/wiktionary -- Note: checking out 'origin/wiktionary'. You are in 'detached HEAD' state. You can [...] :-( Christopher > > The double-dash at the end disambiguates between refs and paths. > > You can use that trick on any command that accepts refspec (branches, > tags, etc) and pathspec (path patterns). > -- > David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "git checkout foo" is getting confused by folder named "foo"
Hi everyone, tl;dr: The short form "git checkout foo" is a mess. There's simply too much "DWIM" magic going on. There are no comprehensible rules how it decides if "foo" is a pathspec or a refspec. On 25 September 2013 15:09, Matthieu Moy wrote: > Jona Christopher Sahnwaldt writes: > >> On 25 September 2013 04:51, David Aguilar wrote: >>> On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt >>> wrote: >>>> Hi, >>>> >>>> maybe this has already been reported, but I didn't find it in the mail >>>> archive. >>>> >>>> If I understand correctly, after I clone a repo, I should be able to >>>> switch to branch foo just by running >>>> >>>> git checkout foo >>>> >>>> This doesn't seem to work if a folder called "foo" exists in the root >>>> of the repo. >>> >>> git checkout foo -- >> >> Thanks for the suggestion, but it doesn't work for me. With both >> 1.7.9.5 and 1.8.3.2, I get this: >> >> $ git checkout wiktionary -- >> fatal: invalid reference: wiktionary > > OK, what happens is that "git checkout wiktionary" is actually a > shorthand for "git checkout -b wiktionary --track origin/wiktionary". No, it isn't. More precisely: if branch "foo" is not yet in .git/config, but there is a branch "origin/foo" and no file/folder "foo" in the root of the project, then "git checkout foo" is short for "git checkout -b foo -t origin/foo" (which in turn can be shortened to "git checkout -t origin/foo", if I understand correctly). Below are the rather arcane rules that I found in 1.7.9.5. They apply if the branch "foo" is not yet configured in .git/config. If branch "foo" is in .git/config I guess "git checkout foo" will always check out branch "foo", no matter if there's a file called "foo" somewhere. I gave up testing them in 1.8.3.2, but I assume its behavior the same. Let's consider several scenarios: 1. there is a branch "origin/foo", but also a *tracked* file/folder "foo" in the *root* folder of the project: a. when I'm in the root folder, "git checkout foo" silently resets the working tree file/folder "foo" to its staged / HEAD version (I think) and prints no response. b. when I'm in a sub-folder that contains a tracked file/folder called "foo", "git checkout foo" silently resets the working tree file/folder "foo" to its staged / HEAD version and prints no response c. when I'm in a sub-folder that cotains *no* *tracked* file/folder called "foo", "git checkout foo" does nothing and prints "error: pathspec 'foo' did not match any file(s) known to git." 2. there is a branch "origin/foo", but also an *untracked* file/folder "foo" in the *root* folder of the project: a. when I'm in the root folder, "git checkout foo" does nothing and prints "error: pathspec 'foo' did not match any file(s) known to git." b. when I'm in a sub-folder containing a *tracked* file/folder "foo", "git checkout foo" silently resets the working tree file/folder "foo" to its staged / HEAD version and prints no response c. when I'm in a sub-folder that contains *no* *tracked* file/folder called "foo", "git checkout foo" does nothing and prints "error: pathspec 'foo' did not match any file(s) known to git." 3. there is a branch "origin/foo", but *no* file/folder "foo" in the *root* folder of the project: a. if I'm in the root folder (no tracked or untracked file/folder "foo"), "git checkout foo" switches to branch "foo" which tracks "origin/foo": b. if I'm in a sub-folder with a (tracked or untracked) file/folder "foo", "git checkout foo" switches to branch "foo" which tracks "origin/foo": 4. there is *no* branch "origin/foo" a. when I'm in root or sub-folder that contains a *tracked* file/folder called "foo", "git checkout foo" silently resets the working tree file/folder "foo" to its staged / HEAD version and prints no response b. when I'm in root or sub-folder that cotains *no* *tracked* file/folder called "foo", "git checkout foo" does nothing and prints "error: pathspec 'foo' did not match any file(s) known to git." All right, I guess there are more cases, but let's leave it at that... > > In other words, it does no
Re: "git checkout foo" is getting confused by folder named "foo"
On 25 September 2013 21:12, Matthieu Moy wrote: > Jona Christopher Sahnwaldt writes: > >> Hi everyone, >> >> tl;dr: The short form "git checkout foo" is a mess. There's simply too >> much "DWIM" magic going on. There are no comprehensible rules how it >> decides if "foo" is a pathspec or a refspec. > > There is a very simple rule: > > What's on the left hand side of -- are refs, what's on the right hand > side are paths. > > When you don't use --, then Git tries to guess, and fails whenever > there's an ambiguity. That's the case I'm concerned with. And I think the guessing confuses users in many cases. It certainly has confused me. > >>> OK, what happens is that "git checkout wiktionary" is actually a >>> shorthand for "git checkout -b wiktionary --track origin/wiktionary". >> >> No, it isn't. > > What I meant was that the short form advised by people were _meant_ to > be a shorthand. > >> Let's consider several scenarios: > > I don't get your point. Is the overly long list a way of complaining? It's a way of showing that human beings can't understand git's guesswork. :-) It was also a (failed) attempt to understand the rules of this heuristic. And an attempt to show the developers that the rules have gotten out of hand. > Are you suggesting a change? Yes, I think the rules for the "short form" (the guessing when there's no --) should be made simpler, or maybe the guessing should be dropped altogether. I don't know. I don't know git well enough to be able to be more specific. I just find the current behavior very confusing. > What do you think about the change I'm proposing? I don't know. It looks like it's not really addressing my specific problem, because as far as I understand it only applies when there is a --. But again, I don't know git well enough. Anyway, thanks for your work. I'm sorry I can't provide more useful input. This "short form" of checkout is just a small feature. I guess I'm bikeshedding here. Cheers, JC > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "git checkout foo" is getting confused by folder named "foo"
On 25 September 2013 22:01, Matthieu Moy wrote: > Jona Christopher Sahnwaldt writes: > >> Yes, I think the rules for the "short form" (the guessing when there's >> no --) should be made simpler, or maybe the guessing should be dropped >> altogether. I don't know. I don't know git well enough to be able to >> be more specific. I just find the current behavior very confusing. > > It can hardly be "simpler" (in the sense "behavior that can be described > with fewer words"), but it could be tightened to be safer. > > When a remote branch $foo exists, a local branch $foo does not, and a > file $foo does, then > > git checkout $foo > > rather likely means "I want to use git checkout's DWIM and create local > branch $foo", but it currently means to Git "checkout file foo from the > index". It would make sense to die here, and require the use of --. That sounds good. A rule like "when A is true, B is false, and C is true, then X" is probably too complex to be useful. It's probably better to give up and say "sorry, I DKWYM (don't know what you mean)". :-) There are a few more ideas, opinions, discussions about all this at http://stackoverflow.com/questions/18833617/why-does-git-checkout-remote-branchname-not-create-new-tracking-branch especially in the comments. Cheers, JC > > No time to write a patch for this. Any volunteer? > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html