You asked what the following command did, and it will do plainly what you tell it to, but you're treating the fact that a/b can be anything you make it to be somehow a fault of checkout, and all because it decided to be nice and try to guess what you really want. I don't understand that line of thought.

The git documentation clearly states what happens in your scenario:

> ARGUMENT DISAMBIGUATION

> When there is only one argument given and it is not -- (e.g. "git checkout abc"), and when the argument is both a valid <tree-ish> (e.g. a branch "abc" exists) and a valid <pathspec> (e.g. a file or a directory whose name is "abc" exists), Git would usually ask you to disambiguate. Because checking out a branch is so common an operation, however, "git checkout abc" takes "abc" as a <tree-ish> in such a situation. Use git checkout -- <pathspec> if you want to checkout these paths out of the index.

See here: https://git-scm.com/docs/git-checkout#_argument_disambiguati...

If you somehow manage to purposefully name things in a confusing manner, you can tell git exactly what you want it to grab at any point in time. I don't possibly see how this is a fault of the tooling.

We might just have different points of view here.

Obviously one can read the documentation carefully and read what's going on, but in practice most users don't. Also, to be fair to users, they often don't know what they don't know -- they aren't aware they should be reading how checkout does argument disambiguation when they start getting weird error messages.

On the other hand, if git didn't allow '/' in branch names, except are a remote/branchname seperator, then we would know what '/' meant -- in practice this is what almost everyone does in practice anyway (there may be a deeper issue here I'm not aware of).

Similarly, if git didn't have commands which could take either a <tree-ish> or a <pathspec>, say have "checkout-file" (that's an awful name, but I'm sure we can find a better one), then there would be no need to have this special bit of documentation, and describe to people how to get around the issue.

My experience of teaching is that git guessing what people want makes learning git harder, as they have to learn what are the fundamentals, and what is git being "helpful".

Yep there's a lot of best practices you learn after using git for a while that is not obvious initially, like not using '/' in branch name (though, I used to have a coworker who always named branches like 'fix/something' or 'feat/something' -- well at least there was a pattern there).

I also don't use most of the git commands directly, I have a bazillion of aliases that are shorter and/or more intuitive.

To be honest, there were some changes for the better in the CLI. For instance 'git push' no longer defaults to the crazy 'matching' behavior, but 'simple' instead.

I guess the problem is perhaps that most of the time, people get used to the quirks and don't report them (maybe I'm mistaken).

In fact, if git bug tracker was hosted on GitHub, I'd probably be more active in reporting and discussing things. I'm not an old school mailing list kind of guy I guess, and maybe not only me (but I believe many git maintainers would say, it's a feature that barrier of entry is not low).

I always use '/' in the branch name and have never had any issues. Can you explain why this would be an issue?

The only issue I am aware of is that beginners often assume, based on basically every tutorial, that / has a special meaning, it is used to denote remote/branchname.

To be fair, issues like this are really only UI issues with some git commands, not necessarily git as a whole. The GP post was probably lamenting a much deeper issue with the design of git.