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

From: A Large Angry SCM <gitzilla@gmail.com>
Date: Sep 14, 2006, 20:08 UTC
Message-ID: <4509B6AA.9040902@gmail.com>
In-Reply-To: <20060914192119.GC10556@spearce.org>

Shawn Pearce wrote:

Show 17 quoted lines

> A Large Angry SCM <gitzilla@gmail.com> wrote:
>> 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.

I was looking for minimal changes to the index and associated code. Either way works.

> 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.

That's a partial working working directory by my definition so it would work. How it's specified on the command line is TBD.

It's desired by a lot of very modular projects.

Show 10 quoted lines

>> [*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.

Directory trees without any changes might actually be less expensive to work with using the split index since you could ignore all of the unchanged entries easily.