odb: move reparenting logic into respective subsystems

The primary object database source may be initialized with a relative
path. When the process changes its current working directory we thus
have to update this path and have it point to the same path, but
relative to the new working directory.

This logic is handled in the object database layer. It consists of three
steps:

  1. We undo any potential temporary object directory, which are used
     for transactions. This is done so that we don't end up modifying
     the temporary object database source that got applied for the
     transaction.

  2. We then iterate through the non-transactional sources and reparent
     their respective paths.

  3. We reapply the temporary object directory, but update its path.

All of this logic is heavily tied to how the object database source
handles paths in the first place. It's an internal implementation
detail, and as sources may not even use an on-disk path at all it is not
a mechanism that applies to all potential sources.

Refactor the code so that the logic to reparent the sources is hosted by
the "files" source and the temporary object directory subsystems,
respectively. This logic is easier to reason about, but it also ensures
that this logic is handled at the correct level.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

0 files changed, 0 insertions, 0 deletions