Re: [PATCH 0/7] Submodules and partial clones

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

 



> I've been investigating what is required to get submodules and partial
> clones to work well together.  The issue seems to be that the correct
> repository is not passed around, so we sometimes end up trying to fetch
> objects from the wrong place.
> 
> These patches don't make promisor_remote_get_direct handle different
> repositories because I've not found a case where that is necessary.

Anything that reads a submodule object without spawning another process
to do so (e.g. grep, which adds submodule object stores as alternates in
order to read from them) will need to be prepared to lazy-fetch objects
into those stores.

> The patches rework various cases where objects from a submodule are
> added to the object store of the main repository.  There are some
> remaining cases where add_to_alternates_memory is used to do this, but
> add_submodule_odb has been removed.
> 
> I expect there will be some remaining issues, but these changes seem to
> be enough to get the basics working.

What are the basics that work?

When I looked into this, my main difficulty lay in getting the
lazy fetch to work in another repository. Now that lazy fetches are done
using a separate process, the problem has shifted to being able to
invoke run_command() in a separate Git repository. I haven't figured out
the best way to ensure that run_command() is run with a clean set of
environment variables (so no inheriting of GIT_DIR etc.), but that
doesn't seem insurmountable.



[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