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

[A Large Angry SCM <gitzilla@gmail.com>]

Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
> 
>> Junio C Hamano wrote:
>> ...
>>> Having said that, I do not necessarily agree that highly modular
>>> projects would want to put everything in one git repository and
>>> track everything as a whole unit.
>> And yet that's exactly how a lot of developers use CVS. You can argue
>> that some other way is better but when they move from CVS they're
>> looking for continuity of productivity which often means not radically
>> changing how they work. At least in the short term.
> 
[...]

> I suspect that everything-under-one-roof approach is coming from
> an observation that:
> 
>  - with CVS, projects that share the same cvsroot can be updated
>    with single 'cvs update' command in a directory close to the
>    root.
> 
>  - with git, if you use multiple repositories checked out at
>    right places in the working tree hierarchy, you need to run
>    around and say "git checkout" or "git commit" everywhere.
> 
> and the latter looks very inconvenient.
> 
> But of course the latter is very inconvenient.  The current "git
> checkout" nor "git commit" are not such subprojects-aware
> Porcelain commands.  But that does not mean you have to house
> everything in the same repository and make partial check-in to
> work.  You will be enhancing or replacing the same "git checkout"
> and "git commit" commands to do so anyway.

I used CVS as an example but I've seen the "everything-under-one-roof" 
approach, as you put it, used in other VCS' that do work with 
changesets. One instance, in particular, has all the source and config 
files in a single tree that (I'm told) would take several Gigs of 
filesystem space to checkout fully. The codebase is modular to a great 
extent but any particular project in it usually required files from a 
large number of other projects. There is a lot of automation to find the 
required parts for builds and other actions on a project's codebase.

Could this be done with multiple repositories? Yes, but we're talking 
hundreds (no exaggeration) and many of those would likely end-up 
including a large percentage of the other repositories the way the Git 
repository includes the Gitk repository. It could work but their 
existing approach already works and is likely better suited for their 
codebase. Git can not, currently, do all the things that this 
organization wants a VCS to do, working with partial checkouts is a key one.

There is no fundamental reason Git can not support partial 
checkouts/working directories. In fact, there is no fundamental reason 
Git can not support operations on partial (sparse?) repositories in both 
space (working content/state, etc.) and time (history); it's just a 
matter of record keeping[*1*]. That isn't how the Linux kernel 
developers want to use their VCS but it _is_ how others want to use theirs.


Notes:
[*1*] I'm currently working on determining the minimum requirements 
needed to support repositories with partial or sparse history.