Re: [PATCH 3/8] docs: use <sha1> to mean unabbreviated ID

Jonathan Nieder [off-list ref] writes:

Mark Lodato wrote:

quoted

There are some places that literally require a full, 40-character SHA-1
ID, rather than a generic revision specifier.

One name I have seen for these is "object IDs", as in git get-tar-commit-id
(to avoid putting too much emphasis on precisely how the identifiers are
chosen).

Yes, I think I also saw "a full object name" (cf. diff --full-index) and
evan "object name" (cf. git-pack-objects(1)).  These are all deliberate
efforts to stay away from spelling SHA-1 explicitly, and I think it makes
sense to do so here.  "40-digit object ID" is a mouthful, though.

As to what this series tries to do, I think it is generally a good idea to
start allowing documents to say <tree> when a reader can plug either a
commit or a tree, rather than <tree-ish>, only because all Porcelains
automatically dereference object names to needed types these days.

But such a change needs to mark places that _must_ take the name of an
object of the specific type somehow.  It is Ok to say ls-tree takes a
tree, but then we must say you should feed commit-tree nothing but a tree.

It is a separate issue to allow plumbings to automatically dereference
when both of the following two conditions hold: (1) the intent is clear
from the context; (2) nobody sane would have been relying on the side
effect of the current typechecking.

Letting commit-tree to unwrap a tree-ish to a tree would be a good example
that clearly satisfies (1)---I am not sure about the other one.