On Thu, Aug 28, 2025 at 7:44 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Julia Evans" <julia@xxxxxxx> writes: > > >> I think we've dropped the bit about the default interpretation of "git > >> checkout <something>". Maybe > >> > >> When you run `git checkout <something>`, Git tries to guess whether > >> `<something>` is intended to be a branch, a commit, or a set of file(s), > >> and then switches branches, switches commits, or restores the files. > >> > >> By default, Git interprets `<something>` as a _<tree-ish>_. > >> [explain what choosing a tree-ish means for the user?] > >> > >> [Your notes on disambiguation as before] > > > > Thanks, will fix. Though I don't think it's accurate that > > Git will treat <something> as a <tree-ish> in this context, since > > `git checkout <tree>` is not valid. Will find a different wording. > > (I get "fatal: Cannot switch branch to a non-commit") Interesting. A docs bug! :) AFAICT it comes from 19e5656345 (checkout.txt: document a common case that ignores ambiguation rules, 2016-09-07). I was a novice then and don't know the behavior from that period, nor did I bother to find out whether "tree-ish" matched the behavior at the time and has changed or was simply wrong from the start. Good catch. > True. "git checkout foo" is disambiguated by seeing if 'foo' can be > interpreted as a commit-ish, and if not, if there is a path 'foo' in > the working tree. Otherwise we'd get an ambiguity error. A commit-ish > that is nameed by giving a branch name and other commit-ish then trigger > a bit different codepaths (the former results in checking out a branch, > the latter detached HEAD). Yep, makes sense. -- D. Ben Knoble
