On Mon, May 4, 2020 at 8:03 PM Han-Wen Nienhuys <hanwen@xxxxxxxxxx> wrote:
> >
> > All this to say - it's hard to convince myself this is a safe change,
> > and I'd really like to read more to understand why you made it.
>
> I'll be the first to admit that I'm on shaky ground here. However,
> given that the test suite passes, if this is breaking some behavior,
> it's probably not very well tested behavior.
>
> Here is what I know:
>
> Git stores refs in multiple places:
> - normal refs, packed: .git/packed-refs
> - normal refs, loose: under refs/*/
> - special refs: HEAD, ORIG_HEAD, REBASE_HEAD.
>
> Currently, the special refs can only be read with refs_read_raw_ref().
> If you iterate over the refs in the files/packed backend, you can
> never find HEAD, ORIG_HEAD etc.
A large source of test failures of the reftable patch series is the
handling of pseudo refs (HEAD, CHERRY_PICK_HEAD etc.)
These are written as
if (ref_type(refname) == REF_TYPE_PSEUDOREF) {
assert(refs == get_main_ref_store(the_repository));
ret = write_pseudoref(refname, new_oid, old_oid, &err);
} else {
t = ref_store_transaction_begin(refs, &err);
..
write_pseudoref writes a file directly to the .git/ directory.
However, on read (for example, CHERRY_PICK_HEAD), the pseudo ref is
given to lookup_commit_reference_by_name, which in the end calls
refs_resolve_ref_unsafe(). If reftable is active, the pseudo ref isn't
read from .git/CHERRY_PICK_HEAD.
If the pseudo refs are read through a ref backend, shouldn't they be
written through a ref backend too?
This causes all rebase and all cherry-pick tests to fail with reftable.
--
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
