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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 27, 2020 at 6:20 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> > On Fri, Jul 17, 2020 at 12:10 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> >> I reviewed some codepaths that deal with FETCH_HEAD recently.
> >>
> >> As the file is quite different from all the other pseudo references
> >> in that it needs to store more than one object name and in that each
> >> ref in it needs more than just the object name, I doubt that it
> >> makes much sense to enhance the refs API so that its requirements
> >> can be covered.
> >
> > I agree. Do we ever pretend that FETCH_HEAD is a ref today?
>
> "git rev-parse FETCH_HEAD", "git show FETCH_HEAD" etc. all should keep
> working, so in that sense, it is treated as a ref.

I added this to the last version of the full reftable patch series
that I posted,  as patches
"Split off reading loose ref data in separate function" and "Read
FETCH_HEAD as loose ref".

Which other refs that aren't really refs should also be supported? The
JGit source code suggests that MERGE_HEAD should also be special
cased?

It's not pretty, though. The entry point is read_raw_ref(), which gets
a ref_store as argument. ref_store doesn't have generic API to get at
the repository directory, so the implementation of reading the
FETCH_HEAD file has to be pushed down to the ref backend (which does
know the directory).

> It does not
> protect the history leading to the objects listed in it from being
> collected, though.

Is there documented agreement of how pseudo refs and GC should interact?

> "git merge FETCH_HEAD" is an interesting case---I haven't thought it
> through.
>
> What should happen after "git pull origin foo bar" attempts to grab
> two branches and make an octopus merge into the branch currently
> checked out, and then "git reset --hard && git merge FETCH_HEAD" is
> given?

I don't understand this question.

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux