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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A Large Angry SCM <gitzilla@xxxxxxxxx> writes:

> The minimum required changes[*1*][*2*][*3*] to the index file to support
> partial checkouts are:
>
> 1) the addition of WD_Prefix string to hold the common path prefix of
> all objects in the working directory. For a full checkout, the WD_Prefix
> string would be empty.
>
> 2) A (new) flag for each entry in the index indicating whether or not
> the object is in the partial checkout.
>
> 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.
>
> All the Git commands that use the index file will need to be changed to
> support this but the transfer protocols do not need to change.

While this may be a good start, you need a lot more than this if
you want to do (1) and (2):

The tree object contained by a commit is by definition a full
tree snapshot, so if you want to do a WD_Prefix, you somehow
need a way to come up with the final tree that is a combination
of what write-tree would write out from such a partial index
(i.e. an index that describes only a subdirectory) and the rest
of the tree from the current HEAD.  I think you can more or less
do this change to Porcelain using today's git core.  The
sequence to emulate it with the today's git would be:

 (1) write-tree (of the WD_Prefix part of the subtree),
 (2) read-tree HEAD (to populate the index fully),
 (3) piping a massaged output from git-ls-files WD_prefix to
     update-index --index-info, followed by read-tree
     --prefix=WD_prefix to swap the partial tree in to
     WD_prefix,
 (4) write-tree (to get the final result).

If you want to do per-path-inside-directory checkout (your 2),
this combining step would need to be even more complex.  You can
do that by hand (reading ls-tree and ls-files and driving
update-index --index-info yourself) but it certainly would be
more involved.  But it's just a matter of Porcelain programming
;-) [*1*].

But a good news is that today's git core lets you work in a
sparsely checked out repository without any of the above
crap^Wcomplexity, if you drop the WD_Prefix and per
path-inside-directory checkout "expectations".  Just staying
within the directory you are working in, and saying "commit ."
when you are tempted to say "commit -a", would be more or less
what are needed.

Note.  The "git checkout" Porcelain would want to check-out
everythingd, so a tool to prepare such a sparsely checked out
tree needs to be written if somebody wants to try this, since
the above "good news" is only about "working in" a sparsely
checked out tree.


[*1*] Obviously you would also need to worry about activities
other than making your own changes and committing.  When you are
always pulling from a single upstream that never rewinds the
head, the problem becomes simpler, but for other cases (read:
anything that makes distributed version control more interesting
and useful) you would need to worry about merges too.  What
happens when the upstream you based your changes on and the
repository you are pulling from today had conflicting changes
outside of your area of interest?  Without resolving the
conflicts, you cannot sanely claim you merged the two branches,
and even if you wanted to resolve them yourself, an non-empty
WD_prefix would get in your way.

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]