[RFD] Overlapping projects

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

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

I'm thinking something like having a head for cogito and a head for git in the same repository, where the trees for git only have the core files, and the commits for cogito have, in addition to a tree with only the cogito-specific files, a reference to a git commit that they include.

It seems to me like this area contains a brilliant idea that I haven't had so far, and maybe someone can come up with it.

	-Daniel
*This .sig left intentionally blank*

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.

On Mon, 9 May 2005, Junio C Hamano wrote:

The directory structure is definitely awkward. I'd personally put cogito stuff in a separate directory. But that's a matter of which paths belong to which commit.

But when Petr adds something to the core, intended for eventual inclusion in the mainline, and uses it in cogito, this breaks everything, because then people have to know to pull both the latest cogito and the latest git from him. If the new git isn't backwards-compatible, then someone building an old cogito would have to somehow find the matching old git.

This is far worse than just including git and sending Linus patches; the only way to make this manageable would be to suspend cogito until git was completely finished.

The important thing, I think, is being able to connect a Cogito with the git it uses, while both are unstable and under active development. It would be nice to be able to have the obvious things happen when you pull the latest cogito and check it out, and when you commit with changes to files from each of them, but that's less important.

	-Daniel
*This .sig left intentionally blank*

DB> But when Petr adds something to the core, intended for eventual inclusion DB> in the mainline, and uses it in cogito, this breaks everything, because DB> then people have to know to pull both the latest cogito and the latest git DB> from him. If the new git isn't backwards-compatible, then someone building DB> an old cogito would have to somehow find the matching old git.

I think we are in agreement and saying the same thing. Yes, if people wants to do mix and match, they should know what they are doing.

Also I do not see any reason not to have GIT that comes from Cogito additional stuff while Linus tree lags behind, which in a sense already has been the case for some commands. Separating directories would make things easier to manage, not harder.

Anyhow let's wait and see what Petr does. He said he has been preparing core backports earlier. No point arguing about his tree without helping him.

On Tue, May 10, 2005 12:56 am, Daniel Barkalow said:

That sounds like a great idea and shouldn't need any brilliant ideas to
implement.  Just need to push a little more multi-head handling down into 
 git.  The Cogito build process could then include a checkout of the
git-core branch.  Would be much cleaner than the way it is handled now.

Sean