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

From: A Large Angry SCM <gitzilla@gmail.com>
Date: Sep 17, 2006, 18:47 UTC
Message-ID: <450D9847.4080308@gmail.com>
In-Reply-To: <7vvenm3h9f.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 12 quoted lines

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

[...]

Show 19 quoted lines

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