Junio C Hamano <gitster@xxxxxxxxx> writes: > ... another important > point (i.e. when a command wants to take a commit but a user gives > it a tag that points at a commit, the command almost always accepts > the tag, finds the commit the tag points at, and uses that commit > instead of the tag ... A side note I forgot to add. A few commands take both commit and tag but want to do different things depending on the kind of object they get, and for them, <commit> and <commit-ish> should be used carefully in the documentation. For example, "git cat-file commit v2.25.0" and "git cat-file tag v2.25.0" do two different things. They should be described as $ git cat-file commit <commit-ish> $ git cat-file tag <tag> "git merge <commit>" and "git merge <tag>" do different things, even though <tag> must be a <commit-ish>. But most of the Git subcommands (including the "cat-file commit" case) peel a tag as needed, so these special cases are minority.