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. -- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
