Re: What’s the intended/reasonable usage patterns for symrefs?

["Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>]

On Mon, Oct 14, 2024, at 12:16, Patrick Steinhardt wrote:
> On Sun, Oct 13, 2024 at 09:57:23PM +0200, Kristoffer Haugsbakk wrote:
>> […]
>> This seems overly restrictive for this day and age though? No?
>
> There at least is no technical reason to restrict this from the ref
> backend's point of view. Neither the "files" nor the "reftable" backend
> enforce any restrictions except the restrictions we have in place for
> any other reference: a ref is either a root ref, a pseudoref or it must
> start with "refs/".
>
> Now the only reason why I'd say that you maybe shouldn't create weird
> symrefs is that tooling isn't prepared to handle them. But that is not
> sufficient reason for me to say that you mustn't create them.

Thanks.  This makes sense. :)

❦

I discovered/re-discovered a pitfall with the following approach:

> Create a `refs/heads/<symref>` which points to a remote-tracking
> branch

Again, so tempting to do for me because you get a shorthand via
`refs/heads`.  And this is indeed fine for read-only operations
(effectively).

But don’t be careless and do something like commit while checked out
here.  Because you are checked out on an ostensibly “proper branch” (not
detached HEAD) and the remote-tracking branch will move forward with a
commit.

So I’ve gone back to using one-level (root-level) symrefs with
all-capital names.  Because git-symbolic-ref(1) allows that and I
haven’t gotten any weird warnings from it.  (I would presumably get
warnings if I then defined a ref named e.g. `refs/heads/M` if `M` was my
top-level symref.)