Re: [PATCH v3 0/3] Remove special casing for PSEUDOREF updates

> On Mon, Aug 10, 2020 at 6:04 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Han-Wen Nienhuys <hanwen@google.com> writes:
>>
>> > Dealing with FETCH_HEAD generically isn't possible unless we extend
>> > the API of the ref backend: the generic ref_store instance doesn't
>> > offer a way to get at the path that corresponds to FETCH_HEAD, so we
>> > can't handle it in refs_read_raw_ref(). In the current reftable
>> > series, FETCH_HEAD is dealt with in the backends separately.
>>
>> I am not sure what the best way would be, but I do not think any
>> existing code writes into it using the refs API at all, even though
>> it may be read only for the first object name using the refs API.
>>
>> And I am not sure if we want to extend the write side API so that
>> the callers can express the full flexibility of that single file.
>
> That's not what I am getting at. I am just interested in how to handle
> FETCH_HEAD in refs_read_raw_ref.
>
>> So perhaps the best way forward would be to ensure that anybody who
>> tries to read from FETCH_HEAD using the ref API reads the first
>> object name in it from $GIT_DIR/FETCH_HEAD file as we've always done
>> since the beginning of time, regardless of what ref backend is used,
>
> Right, but how do we get at the value of $GIT_DIR given a struct
> ref_store? We can either push that out to the ref store backend,
> because each backend knows what $GIT_DIR is, or we can make $GIT_DIR a
> property of the generic ref_store.
>
> I suppose it's cleaner to make the latter API extension.