Re: [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir

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

 



Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:

>>> .... For example, extra refs added in builtin/clone.c is used by
>>> builtin/fetch-pack.c, meaning that the codepath that discovers and
>>> remembers these extra history anchor points and the codepath that uses
>>> them while walking the history are not localized and we would need some
>>> sort of "extra ref API" anyway. I am leaning towards this option.
> ...
> Namely, we should figure out what code wants to set extra refs and or
> wants to include extra refs in its iteration over references. The
> setters don't have to be changed, but the readers should be.

You read me correctly. That is exactly what I meant by "extra ref API" in
my earlier response.

> ...  But there are so many calls to the
> for_each_ref*() family of functions that I wasn't able to determine
> exactly which should allow for extra refs and which shouldn't.

Only the ones that follow add_extra_ref() in the control flow.

builtin/clone.c adds them in setup_reference() to deal with --reference.
The objects known to be complete in these repositories we borrow from
need to be marked complete on our end (i.e. clone does not have to fetch)
and transport_fetch_refs() that eventually goes to fetch_refs_via_pack()
that calls fetch_pack() uses this information. All three for_each_ref()
calls in builtin/fetch-pack.c are about "what are the objects that we know
are complete?" and needs to pay attention to extra refs.

Having said that, I have a slight suspicion that you might be able to
eliminate this one in clone.  setup_reference() adds the reference
repository to the $GIT_DIR/objects/info/alternates, and the fetch logic
already knows to account for the refs in alternate repositories via
insert_alternate_refs() callchain.

builtin/receive-pack.c adds them in add_alternate_refs() to deal with the
repositories listed in $GIT_DIR/objects/info/alternates in the receiving
end of a push. Again, the objects known to be complete in these
repositories we borrow from need to be marked complete on our end, and
write_head_info() in that function sends these extras together with real
refs we have.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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