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

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

On Wed, Aug 5, 2020 at 5:54 PM Junio C Hamano <gitster@pobox.com> wrote:
> >> All of which means FETCH_HEAD is special and we may not want to
> >> burden the special casing of it to newer backends.
> >
> > Can you confirm that FETCH_HEAD is the only thing that can store more
> > than just a symref / SHA1 ? Based on the name, and a comment in the
> > JGit source, I thought that MERGE_HEAD might contain more than one
> > SHA1 at a time.
>
> No I cannot.  I do not think MERGE_HEAD is something I added with as
> deep a thought as I did with FETCH_HEAD.  If it mimics FETCH_HEAD,
> then perhaps it does, but I somehow doubt it.
>
> As can be seen in builtin/merge.c::collect_parents(), we do special
> case FETCH_HEAD when grabbing what commit*S* to merge, but all
> others are read with get_merge_parent() that makes a single call to
> get_oid(), i.e. anything other than FETCH_HEAD cannot have more than
> one object recorded.

Understood. Is there anything you'd like me to do with this patch
series so it can be merged?

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.

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