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

From: Jakub Narebski <jnareb@gmail.com>
Date: Jun 30, 2019, 09:30 UTC
Message-ID: <86a7dz4e06.fsf@gmail.com>
In-Reply-To: <20190626084139.30246-1-pclouds@gmail.com>

Bikeshed painting ahead.

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

Show 20 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.
>
> - <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