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

> On Wed, Oct 16, 2024, at 19:23, Kristoffer Haugsbakk wrote:
>> On Mon, Oct 14, 2024, at 12:16, Patrick Steinhardt wrote:
>> > […]
>>
>> 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.)
>
> Another newbie mistake.
>
> I used e.g. `H` (root level).  But then I was in a worktree and
> discovered that these root-level refs are per worktree.
>
> But this works across worktress:
>
> ```
> git symbolic-ref refs/H HEAD
> ```
>
> (Or `refs/h`)