Re: [PATCH 1/5] doc: git-checkout: clarify intro
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 28, 2025, 23:44 UTC
- Message-ID
- <xmqqa53jqaen.fsf@gitster.g>
- In-Reply-To
- <f440d0e4-0754-49a0-9677-980f60a5dbf5@app.fastmail.com>
"Julia Evans" <julia@jvns.ca> writes:
Show 16 quoted lines
>> 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")
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).