Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes:
> 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.
