On Wed, Aug 5, 2020 at 5:54 PM Junio C Hamano <gitster@xxxxxxxxx> 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
