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. 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, that anybody who tries to write FETCH_HEAD using the ref API gets an error, and letting the writers write into it directly?
