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

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Nov 4, 2024, 10:45 UTC
Message-ID: <4e3c2840-37f3-43f8-9d8a-b4a106d8d18a@app.fastmail.com>
In-Reply-To: <7347e29a-f33e-472b-b993-06c4767a9456@app.fastmail.com>

On Wed, Oct 16, 2024, at 19:23, Kristoffer Haugsbakk wrote:

Show 26 quoted lines

> 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`)

-- 
Kristoffer Haugsbakk