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

Han-Wen Nienhuys [off-list ref] writes:

On Mon, Aug 10, 2020 at 6:04 PM Junio C Hamano [off-list ref] wrote:

quoted

Han-Wen Nienhuys [off-list ref] writes:

quoted

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.

quoted

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.

Yup.  Sounds like the right direction to go.

Thanks.