Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes: > On Mon, Aug 10, 2020 at 6:04 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> Han-Wen Nienhuys <hanwen@xxxxxxxxxx> 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. Yup. Sounds like the right direction to go. Thanks.
