Re: Notes on supporting Git operations in/on partial Working Directories

From: Shawn Pearce <spearce@spearce.org>
Date: Sep 14, 2006, 19:21 UTC
Message-ID: <20060914192119.GC10556@spearce.org>
In-Reply-To: <4509A7EC.9090805@gmail.com>

A Large Angry SCM <gitzilla@gmail.com> wrote:

Show 5 quoted lines

> The contents of the index file still reflect the full tree but flag each
> object (file or symlink) separately as part of the checkout or not. The
> WD_Prefix string is so that a partial checkout consisting of only
> objects somewhere in the a/b/c/d/ tree can be found in the working
> directory without the a/b/c/d/ prefix to the path of the object.

Why not just load a partial index?

If we only want "a/b/c/d" subtree then only load that into the index. At git-write-tree time return the new root tree by loading the tree of the current `HEAD` commit and walking down to a/b/c/d, updating that with the tree from the index, then walking back updating each node you recursed down through. Finally output the new root tree.

The advantage is that if you have a subtree checked out you aren't working with the entire massive index.

But how does this let the user checkout and work on the 10 top
level directories at once and perform an atomic commit to all
of them, but not checkout the other 100+ top level directories?
As I recall this was desired in the Mozilla project for example.

> [*3*] Possibly split the index up by directory and store the parts in
> the working directory. An index "distributed" in this way would have
> a "natural" cache-tree built in and (finally) be able support empty
> directories.

Please, no. On a project with a large number of directories operations like git-write-tree would take a longer time to scan the index and generate the new trees. I unfortunately work on such projects as its common for Java applications to be very deeply nested and large projects have a *lot* of directories.

-- 
Shawn.