Re: [PATCH] receive-pack: fix crash on out-of-namespace symref

From: Troels Thomsen <troels@thomsen.io>
Date: Dec 28, 2025, 16:26 UTC
Message-ID: <a16bf8a6-2f57-4794-91b5-92615f184c4b@app.fastmail.com>
In-Reply-To: <xmqqfr8uk61i.fsf@gitster.g>

On Sun, Dec 28, 2025, at 15:57, Junio C Hamano wrote:

Show 13 quoted lines

> Fixing crash is certainly a good thing, but when the namespace is
> segregated and receive-pack wants to get updates only within the
> given namespace, would presence of such a cross namespace symref
> cause updates outside the namespace through the symref, defeating
> the point of setting up a namespace in the first place?
>
> I am not objecting to the new behaviour, but am not sure if it is a
> sensible one.  You _might_ be able to argue that an attempt to update
> underlying refs outside the namespace through such a symbolic ref
> should result in an error (i.e., a fix to the current crashing
> behaviour is to die in a controlled way).
>
> Thoughts?

I think it's important that the symbolic ref needs to be explicitly created on the receiving side.

An argument in favor of allowing updates is that you can still choose to reject them by implementing an update hook. Would the opposite be true? I explictly wanted to share a branch into a namespace and update it from there.

I suppose the behavior could be configurable. Given this bug has existed since 2016, I'm assuming namespaces and symbolic refs probably aren't used in combination frequently enough to justify this over using a hook.

-- 
Troels Thomsen