Re: [PATCH 15/32] unpack_trees: only unpack $GIT_DIR/narrow subtree in narrow repository

[Elijah Newren <newren@gmail.com>]

Hi,

2010/8/24 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> 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?