Bikeshed painting ahead.
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.
>
> - <ref>@{literal} only accepts full ref. No turning "master" into
> "refs/heads/master".
>
> - <output>@{describe} interprets <output> as git-describe output
> only, not an object name or a reference.
>
> This gives scripts much better control over get_oid(), which
> translates to rev-parse and a bunch other commands.
>
> PS. The new syntax can stack with existing ones. E.g. you could write
> refs/heads/master@{literal}@{yesterday} or <hash>@{hash}^{tree}.
> Perhaps I should allow these tags at the end too, so you can enforce a
> variable like "$REV"@{literal} where $REV could be even HEAD~123
I think it would be better to use <hash>^{hash} instead of
<hash>@{hash}.
The <ref-ish>@{<something>} is used currently for information that is
outside the DAG, like @{<date>}, @{<n>}, @{-<n>} uses information from
reflog, and @{upstream} and @{push} uses information from the config.
On the other hand ^{<type>}, ^{/<search text>}, and the future
^{<hashalgo>} all use DAG-only information.
Though one could argue that refs information _is_ outside the DAG...
P.S. We have 'git show-ref --verify' that requires exact match (no
DWIM-mery), which can be used together with '--quiet' in a script.
But this doesn't allow for checking if an exact match, or a describe
output exists in repository.
Thanks for taking it up,
--
Jakub Narębski
