Re: [PATCH/RFC] get_oid: new extended SHA-1 syntax to control resolution process

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 26, 2019, 18:51 UTC
Message-ID: <xmqqk1d8ch9g.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190626084139.30246-1-pclouds@gmail.com>

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

Show 6 quoted lines

> The problem is we try every possible way to resolve a rev. Let's have
> some annotation to express that we only want to resolve a rev in a
> certain way:
>
> - <hash>@{hash} only accepts a full hash or a short hash. If it's a
>   short hash, it cannot be ambiguous.

This is to defeat something like refs/heads/deadbeef (the branch whose name is "deadbeef") interfering an object whose name begins with that hexadecimal substring. Makes sense.

> - <ref>@{literal} only accepts full ref. No turning "master" into
>   "refs/heads/master".

This is already doable by saying "refs/heads/master", isn't it? Any ambiguous ones like a branch or a tag whose name is 'refs/heads/master' (i.e. refs/heads/refs/heads/master and refs/tags/refs/heads/master respectively) won't interfere once you use the explicit prefix refs/ like so. I'd rather not to see this one added.

> - <output>@{describe} interprets <output> as git-describe output
>   only, not an object name or a reference.

Again this is to defeat refs/heads/v2.22.0-221-gdeadbeef branch interferring with the object "deadbeef" thusly described. Makes sense.

In the above, my two "Makes sense" only refer to the capability the syntax allows us to have, not the suggested syntax itself (which I am not convinced is a good use of @{<token>} yet).

Thanks.