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

[Han-Wen Nienhuys <hanwen@google.com>]

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.

-- 
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