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

>> c) Replace the backpointer with a remote_state parameter. Expressive and
>>    fits the paradigm of "defaulting to the repo when needed", but
>>    interfaces are repetitive and shifts the responsibility of
>>    correctness to the caller (see v2).
> 
> ... if we want to support the what-if callers, I
> think the best approach would be a slight variant of c) above.
> 
> That is, pass branch and remote_state as two parameters, and when
> branch is not NULL, barf if it is not among remote_state.branches[],
> to protect against nonsense combinations.

>>> 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.
> [...] 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.