Re: [PATCH 3/8] docs: use <sha1> to mean unabbreviated ID
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 18, 2010, 18:50 UTC
- Message-ID
- <7voc8ihq4a.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20101218074718.GA6187@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 8 quoted lines
> 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.