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

From: Han-Wen Nienhuys <hanwen@google.com>
Date: Aug 10, 2020, 14:27 UTC
Message-ID: <CAFQ2z_OgNQKZ23gNB9=LqPn2M=WKL2vPQQpxm3drRWeN1sxH_A@mail.gmail.com>
In-Reply-To: <xmqqk0ydozqe.fsf@gitster.c.googlers.com>

On Wed, Aug 5, 2020 at 5:54 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 17 quoted lines

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