Re: [PATCH v3 2/3] Modify pseudo refs through ref backend storage

From: Han-Wen Nienhuys <hanwen@google.com>
Date: Jul 27, 2020, 15:41 UTC
Message-ID: <CAFQ2z_M-OcJA_a3QZ2QfzREM2JHN6G89HKPuccUUSwKWbp_Fdw@mail.gmail.com>
In-Reply-To: <nycvar.QRO.7.76.6.2007171042461.54@tvgsbejvaqbjf.bet>

On Fri, Jul 17, 2020 at 12:18 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 9 quoted lines

> The reason is that there exists a `refs/heads/foo` _and_ the symref `FOO`
> (which points to `refs/heads/master`, which is at 1e995a).
>
> An earlier symptom of this bug is visible on Linux, too, though: when
> you run t1405.4 'delete_refs(FOO, refs/tags/new-tag)', it shows this:
>
>         + git rev-parse FOO --
>         warning: ignoring dangling symref FOO
>         fatal: bad revision 'FOO'

Thanks, this was very helpful for debugging.

The reason is that we do split_symref_update(), where a transaction that modifies SYMREF (pointing to REFERENT) without REF_NO_DEREF is changed to a transaction that modifies REFERENT and a reflog-only update for SYMREF. In this case, that leaves the FOO symref in place.

This seems very specific to the test (is there any use of symrefs beyond HEAD?) , and I fixed it by passing REF_NO_DEREF to the delete-refs call.

It would also be nice if this behavior was lifted out of the files backend and into the generic layer, but it's not yet clear to me if this is possible.

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