On Tue, Dec 29, 2020 at 7:22 PM Ulrich Spörlein <u...@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
