Re: [PATCH 15/32] unpack_trees: only unpack $GIT_DIR/narrow subtree in narrow repository
- From
Elijah Newren <newren@gmail.com>
- Date
- Aug 25, 2010, 05:04 UTC
- Message-ID
- <AANLkTinaF6e+bfVqRRThuZ=2PjpOs4P88RKFsxOTVSJR@mail.gmail.com>
- In-Reply-To
- <1282688422-7738-16-git-send-email-pclouds@gmail.com>
Hi,
2010/8/24 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
Show 13 quoted lines
> By definition, narrow repository is incomplete. It does not even have > enough tree for a single commit. So populating a full index is > impossible. > > Because of this, unpack_trees() is modified to only unpack trees > within $GIT_DIR/narrow, which narrow repo has all needed trees. This > makes the resulting index unsuitable for creating commits later on. > This is the reason index version is increased to 4, to avoid older > git from using it. > > The resulting tree objects created from the index is only part of the > full tree. Manipulation will be needed at commit time to create proper > tree for commits.
I spent a while thinking about this a couple weeks ago and never came to a strong conclusion about which of two alternatives should be preferred; I'm curious why you decided to go for this solution. An alternative I thought of was having the index have entries for missing files (whose contents did not exist in the repository or the working copy; rather all we know is the filename and its sha1sum) and also gain the ability to have entries for missing trees (which behave similarly; all we know is their name and their sha1sum, but the contents of that sha1sum are not in the repository or the working directory) Is there a reason to prefer one alternative over the other? Does the alternative I thought of even make sense?