[PATCH] Handle tags outside of refs/tags gracefully.

[Jason A. Donenfeld]

On Tue, Dec 29, 2020 at 7:22 PM Ulrich Spörlein <uqs at freebsd.org> wrote:
>
> On Tue, 2020-12-29 at 12:37:43 +0100, Jason A. Donenfeld wrote:
> >This is for the tag UI, though. Aren't tags supposed to live in
> >refs/tags/ by definition?
> >
> >Special casing "refs/" also winds up breaking repositories that
> >accidentally push tags literally named 'refs/tags/something'. I've
> >seen this happen quite a few times in the real world.
>
> Nothing is really enforced by git, so you can put tags anywhere (and
> suffer the consequences). We decided to have these tags not be pulled by
> default and stashed them under refs/backups/foo so they are not directly
> user visible after a default clone.
>
> If I ask for the tag refs/backups/foo, I expect it to look for that, and
> not for refs/tags/refs/backups/foo. That is what I feel most of the git
> commands do, that need to look up a ref. It was just striking how the
> log handler does handle this just fine (as does the git CLI).

The fact that the git CLI handles it properly actually is a compelling
reason to mimic its logic. How does it handle this scenario? I assume
it looks up both possibilities and returns the first one that matches?
In which order does it check?

Jason