threads / discuss / 44301

Re: Automagic `git checkout branchname` mysteriously fails

Subject: Re: Automagic `git checkout branchname` mysteriously fails

## tl;dr

4 messages between Oct 16, 2016 and Oct 17, 2016.

replies: 3people: 3as markdown or json

Martin Langhoff· Oct 14, 2016, 20:25 UTC · lore

Automagic `git checkout branchname` mysteriously fails

In a (private) repo project I have, I recently tried (and failed) to do:

  git checkout v4.1-support

getting a "pathspec did not match any files known to git" error.

There's an origin/v4.1-support, there is no v4.1-support "local" branch. Creating the tracking branch explicitly worked.

Other similar branches in existence upstream did work. Autocomplete matched git's own behaviour for this; where git checkout foo woudn't work, autocomplete would not offer a completion.

Why is this?

One theory I have not explored is that I have other remotes, and some have a v4.1-support branch. If that's the case, the error message is not very helpful, and could be improved.

git --version 2.7.4

DWIM in git is remarkably good, even addictive... when it works :-)

cheers,

-- 
 martin.langhoff@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted        ~  http://github.com/martin-langhoff
   by shiny stuff

Kevin Daudt· Oct 14, 2016, 20:58 UTC · re: Martin Langhoff · lore

On Fri, Oct 14, 2016 at 04:25:49PM -0400, Martin Langhoff wrote:

Show 26 quoted lines

> In a (private) repo project I have, I recently tried (and failed) to do:
> 
>   git checkout v4.1-support
> 
> getting a "pathspec did not match any files known to git" error.
> 
> There's an origin/v4.1-support, there is no v4.1-support "local"
> branch. Creating the tracking branch explicitly worked.
> 
> Other similar branches in existence upstream did work. Autocomplete
> matched git's own behaviour for this; where git checkout foo woudn't
> work, autocomplete would not offer a completion.
> 
> Why is this?
> 
> One theory I have not explored is that I have other remotes, and some
> have a v4.1-support branch. If that's the case, the error message is
> not very helpful, and could be improved.
> 
> git --version
> 2.7.4
> 
> DWIM in git is remarkably good, even addictive... when it works :-)
> 
> cheers,
>

Correct, this only works when it's unambiguous what branch you actually mean.

if remote_a/branch and remote_b/branch exists, git cannot guess which one you actually mean.

The message you get is because git checkout can be followed by several things. Either a branch/commit or a file. Git complaining it cannot find a file with that name is because it has exhausted all other options.

I do agree that message could be a bit more clear.

Martin Langhoff· Oct 14, 2016, 21:06 UTC · re: Kevin Daudt · lore

On Fri, Oct 14, 2016 at 4:58 PM, Kevin Daudt <me@ikke.info> wrote:

> Correct, this only works when it's unambiguous what branch you actually
> mean.

That's not surprising, but there isn't a warning. IMHO, finding several branch matches is a strong indication that it'll be worth reporting to the user that the DWIM machinery got hits, but couldn't work it out.

I get that process is not geared towards making a friendly msg easy, but we could print to stderr something like:

 "branch" matches more than one candidate ref, cannot choose automatically.
 If you mean to check out a branch, try git branch command.
 If you mean to check out a file, use -- before the pathname to
 disambiguate.

and then continue with execution. With a bit of wordsmithing, the msg can be made to be helpful in the various failure modes.

cheers,

-- 
 martin.langhoff@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted        ~  http://github.com/martin-langhoff
   by shiny stuff

Duy Nguyen· Oct 17, 2016, 11:39 UTC · re: Martin Langhoff · lore

On Sat, Oct 15, 2016 at 4:06 AM, Martin Langhoff <martin.langhoff@gmail.com> wrote:

Show 16 quoted lines

> On Fri, Oct 14, 2016 at 4:58 PM, Kevin Daudt <me@ikke.info> wrote:
>> Correct, this only works when it's unambiguous what branch you actually
>> mean.
>
> That's not surprising, but there isn't a warning. IMHO, finding
> several branch matches is a strong indication that it'll be worth
> reporting to the user that the DWIM machinery got hits, but couldn't
> work it out.
>
> I get that process is not geared towards making a friendly msg easy,
> but we could print to stderr something like:
>
>  "branch" matches more than one candidate ref, cannot choose automatically.
>  If you mean to check out a branch, try git branch command.
>  If you mean to check out a file, use -- before the pathname to
>  disambiguate.

Or even better, list all ambiguous candidates like Jeff did for ambiguous short SHA-1 in 1ffa26c (get_short_sha1: list ambiguous objects on error - 2016-09-26).There were a few occasions I was confused by ambiguous refs and displaying them all would help me see what problem was much faster.

-- 
Duy