Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Mark Lodato wrote: > >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html