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

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

On Mon, Nov 4, 2024, at 11:45, Kristoffer Haugsbakk wrote:
> 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`)

I’ve been using some shorthands for over half a year now:

```
git symbolic-ref refs/C refs/heads/<longer branch name>
git symbolic-ref refs/O refs/remotes/origin/<longer branch name>
```

E.g. I find the latter convenient for referring to some long-living
branch that is also long-named.  I use the remote-tracking branch
directly to use as the upstream-tracking ref and to rebase on top of.

I haven’t had any problems yet.

-- 
Kristoffer Haugsbakk