From: "Junio C Hamano" <gitster@xxxxxxxxx>
Sent: Thursday, November 02, 2017 4:23 AM
Junio C Hamano <gitster@xxxxxxxxx> writes:
The reason why we say "-ish" is "Yes we know v2.15.0 is *NOT* a
commit object, we very well know it is a tag object, but because we
allow it to be used in a context that calls for a commit object, we
mark that use context as 'this accepts commit-ish, not just
commit'".
Having said all that, there is a valid case in which we might want
to say "blob-ish".
Is this not also an alternative case, relative to the user, for the scenario
where the user has an oid/sha1 value but does not know what it is, and would
like to find its source and type relative to the `describe` command.
IIUC the existing `describe` command only accepts <commit-ish> values, and
here we are extending that to be even more inclusive, but at the same time
the options become more restricted. Thus the synopsis terminology would be
more about suggesting the range of options available (search style/start
points) that are applicable to blobs, than being exactly about the
'allow-blobs' parameter.
Or have I misunderstood how the fast commit search and the slower
potentially-a-blob searching are disambiguated?
--
Philip
To review, X-ish is the word we use when the command wants to take
an X, but tolerates a lazy user who gives a Y, which is *NOT* X,
without bothering to add ^{X} suffix, i.e. Y^{X}. In such a case,
the command takes not just X but takes X-ish because it takes a Y
and converts it internally to an X to be extra nice.
When the command wants to take a blob, but tolerates something else
and does "^{blob}" internally, we can say it takes "blob-ish".
Technically that "something else" could be an annotated tag that
points at a blob object, without any intervening commit or tree (I
did not check if the "describe <blob>" code in this thread handles
this, though).
But because it is not usually done to tag a blob directly, it would
probably be not worth to say "blob-ish" in the document and cause
readers to wonder in what situation something that is not a blob can
be treated as if it were a blob. It does feel like we would be
pursuing technical correctness too much and sacrificing the readability
of the document, at least to me, and a bad trade-off.
