On Wed, Aug 5, 2020 at 3:45 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> > I'd think all .git/${SOMETHING}_HEAD are of transitory nature that
> > can be left as simple on-disk files that are read (and preferrably
> > written---except for FETCH_HEAD for obvious reasons) as if they are
> > loose refs handled by files backend.
>
> Sorry for flipping and flopping. The above goes directly against
> the spirit of 09743417 (Modify pseudo refs through ref backend
> storage, 2020-07-27). I still think .git/${SOMETHING}_HEAD except
> for FETCH_HEAD should be written and read via the ref subsystem, but
> I was wrong to say that it should always be done via the files
> backend. There is no reason to insist on the use of files backend
> here.
Yes, that confused me. Thanks for setting that straight.
> > If the octopus merge does not finish correctly (e.g. due to
> > conflicts), with "git reset --hard", we can recover to the original
> > state and re-attempt the opeation with "git merge FETCH_HEAD". Such
> > a merge using FETCH_HEAD will produce an octopus merge.
> >
> > Which means that at least "git merge", FETCH_HEAD is not just a
> > regular ref where you can ask what object it points at and it gives
> > you a single object name back.
> >
> > But to other commands like "git log master..FETCH_HEAD", it acts as
> > if there is only one object recorded.
>
> 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.
--
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
