mhagger@xxxxxxxxxxxx writes:
> I'm still not clear on how extra_refs are used. Are they generated
> from local refs or are they generated from remote refs? If the
> latter, then it is probably irresponsible not to do *some* sanity
> checking in add_extra_ref() to prevent any chance of refnames like
> "../../../etc/passwd".
No, add_extra_ref() already tells us what their values are, these are
never used to actually read from filesystem. Their refname field has
almost no value other than for debugging and we probably shouldn't even
insist on uniqueness among extra refs or for that matter collision with
the real refs. As I mentioned in an earlier message, their only raison
d'être is to be found by for_each_ref() that feeds revision machinery with
up to which commits we know we have complete histories for. A sample call
chain looks like this:
- cmd_clone()
- setup_reference()
- add_one_reference()
- add_extra_ref()
adds refs in other repositories we borrow from as "extra"
- transport_fetch_refs()
- fetch_refs_via_pack()
- fetch_pack()
- do_fetch_pack()
- find_common()
- for_each_ref(rev_list_insert_ref)
That way find_common() thinks histories leading to these extra refs are
already complete on our end (i.e. we have all the necessary objects), and
by subtracting that from what we are asking from the other end, we can
reduce the amount of history that needs to be transferred.
--
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