Re: [PATCH 6/7] builtin/describe.c: describe a blob
- From
Philip Oakley <philipoakley@iee.org>
- Date
- Nov 4, 2017, 21:15 UTC
- Message-ID
- <BFE987312194406AAAEA8DAC7EC5BFF5@PhilipOakley>
- In-Reply-To
- <xmqq375xs3zr.fsf@gitster.mtv.corp.google.com>
From: "Junio C Hamano" <gitster@pobox.com> Sent: Thursday, November 02, 2017 4:23 AM
Show 10 quoted lines
> Junio C Hamano <gitster@pobox.com> 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
Show 22 quoted lines
>
> 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.
>
>