Re: [PATCH v3 2/4] remote: use remote_state parameter internally

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 26, 2021, 01:22 UTC
Message-ID: <xmqqbl3czik5.fsf@gitster.g>
In-Reply-To: <xmqqfssozk8r.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

>> a) Represent detached HEAD with a non-NULL "struct branch". This will
>>    let us continue using the remote_state backpointer, which makes many
>>    interfaces clean, but is somewhat invasive, error-prone and it uses
>>    "struct branch" for something that is not a branch, which is itself
>>    an error-prone interface.
>
> I'd rather not to go there.

Actually, I take half of that back, as I think this would be the best direction in the longer term, and it conceptually is sound. After all, detached HEAD is not all that special--- when we ask for the "current branch" and the HEAD happens to be detached, we treat it as a perfectly valid state and behave as if we are on that unnamed branch. The state probably deserves to be represented as a "struct branch" instance.

I do agree with you that this approach would involve significant short-term pain, as a lot of existing code may say "NULL is how we represent detached HEAD" and they have to be identified and upgraded before the above plan calls for.

So, I tend to think that in the shorter term, perhaps a safer variant of (c) that allows us to ask "not-current@{push}" would be a good way to go, but when things have stabilized, we should revisit and see if it is feasible to represent a detached HEAD state with an instance of "struct branch" and how simpler the interface would become when we did so.

Thanks.