Re: [RFC] Support projects including other projects

[Junio C Hamano <junkio@cox.net>]

>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:

Daniel, I am sorry but I realize I completely misunderstood what
you meant by "projects including other projects".  What you are
trying to solve is the problem of feeding core GIT changes and
pure Cogito changes separately to the upstream _within_ _the_
_current_ _source_ _tree_ _structure_ of Cogito, isn't it?
That's where your juggling index files and other complexity
comes from, and I did not realize that was what you were talking
about.  I should have realized it when you mentioned kbuild.

Well, personally I do not think such project _overlays_ are
worth supporting because it happens rarely, and to a certain
extent it is simply an undisciplined way to organize the source
tree.  Kbuild case may be justified, but I vaguely recall
something very similar build infrastructure was used by busybox
folks---it could be using just their own copy of kbuild for that
matter.

But as you said in a separate message, I agree that core GIT
layer is meant to be independent from what Porcelain you put on
it.  The relationship between Cogito and core GIT is not similar
to kbuild and the kernel.  It is more like a random X11
application and Xlib.  Having them in the same source tree,
intermixed, is less than optimal.

I would not be surprised when future, if not the next, Cogito
release has source tree organized more like JIT sources,
shipping git-pb and cogito in separate directories, managed by
separate GIT_DIR.  That would make Pasky's life a lot simpler.

And once the separation happens, the issue becomes just a simple
package version matching every distribution does (e.g. Debian's
binary package and library dependencies, or source Build-Depends
dependencies), which is something already has been solved.