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