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

From: A Large Angry SCM <gitzilla@gmail.com>
Date: Sep 15, 2006, 18:15 UTC
Message-ID: <450AEDBF.9050307@gmail.com>
In-Reply-To: <7v8xkl26kb.fsf@assigned-by-dhcp.cox.net>

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.

> The primary audience of git, the kernel project, is reasonably
> modular (although Andrew seems to be suffering from subsystem

I no longer believe that the Linux kernel developers are the "primary audience". They are certainly an important and influential set of Git users but there are also a lot of non kernel projects using Git. If not now, there will soon be more non kernel Git users than kernel Git users.

[Nice description of how to work with the Linux kernel code base.]

[Nice description of one way a hypothetical project with dependencies on libraries under active development could work.]

Show 11 quoted lines

> I think what truly huge but highly modular projects need is a
> good support to lay-out check-outs from multiple subprojects,
> each of which is managed in its own repository but has loose
> (looser than the level of individual commits) version
> dependency.  That would need to solve three issues: (1) the
> right versions from many repositories need to be checked out in
> correct locations for a build, (2) after building and testing to
> make sure they work together as a whole, these specific versions
> from the subcomponent repositories need to be tagged to mark a
> release, and (3) maybe a single large tarball that contains all
> subprojects' checkout can be made easily.

> So the issue may not be partial repository support, but support
> for managing multiple projects.

There's no question that that may be better for some projects. But I believe that the project members (or owners) should decide how they use their tools.