Re: [RFD] Overlapping projects

DB> It seems to me like projects like cogito which are based on a core which DB> is itself a project and which is also part of other projects would benefit DB> from some sort of support.

I personally feel supporting that kind of development directory structure is backwards, and Cogito is a very bad example for it.

Things could have been structured in such a way to have Cogito and core GIT in separate directories hanging from the top level, and Cogito can borrow pieces of GIT from the neighboring directory if it needed to build specialized binary using libgit.a. Unless Petr makes changes to core GIT that is _too_ specific for general use (read: does not meet Linus' taste), we should be able to port the nicer changes made to the core GIT for Cogito's use (like git-ls-files "-t" flag) back to core GIT and there would not be a reason for Cogito to keep carrying its own copy of modified core GIT.

DB> In particular, it would be nice if Linus could pull the DB> changes to the core without getting the wrapper programs at DB> all.

Yes, that is a very desirable arrangement.

However, that does not require to keep them in the same repository. Cogito _could_ have been shipped this way:

                      + (top-level)
                     / \
                    cg git
     (Cogito sources)   (copy of core GIT files)
     .git/ for Cogito   .git/ for core GIT
     only

with an instruction like:

    The tarball contains cg and git subdirectories.  cg part
    implements Cogito, and git part is a copy of recent if not
    latest core GIT.  Go to cg and type "make" to build both of
    them.  Theoretically they can be independently updated to
    the latest but preferred combination is to use at least this
    release of core GIT to use this version of Cogito ...

Maybe I am being too idealistic. I do not deny there are people who want to manage "projects within projects" structure and other people like CVS, subversion and arch do support that style. My impression about them is that the way CVS does it via CVSROOT/modules looked like an ugly hack bolted onto it as an afterthought, external stuff subversion uses did not feel quite right (although nicer than what CVS does), and what arch does was more reasonable but the boundary between SCM and build environment was quite blurry there. And many people "wanting to do so" and other people "supporting doing it" do not necessarily make that right.