Re: [RFC] Support projects including other projects

DB> When a particular cogito commit is made, it is impossible to tell whether DB> the next git-pb will work with it; the current set of patches could be DB> rejected in mainline git, and different support for the same functionality DB> added which requires something different from cogito...

 ... Many problems with the approach of saying "this Cogito
     requires this git-pb" omitted here; I agree that alone
     may not solve problems ...

DB> I think your idea is theoretically possible, but that it is just too DB> impractical...

I do not think it is my idea. Maybe I misunderstood what you meant, but here is what you wrote in the message I responded to.

    ... There is a bit of convenience to having the tools magically
    do the right thing when you check out the child project, but the
    thing that really requires tool support is that you need to be
    able to find the version of git-pb which matches the version of
    cogito you're trying to build (and you might be searching the
    history for where a bug was introduced, so you may not be able
    to use the latest of either).

That part is fine. I already agreed that recording such version dependency would be a good thing. I disagreed with the "solution", however, of having that recorded at the core level:

    The solution is to add a header to commits: "include {hash}",
    which simply says that the given hash, which is from the core
    project, is the commit needed to build this commit of the
    non-core project. This comes from an argument to commit-tree
    ("-I", perhaps), and the parsing code needs to identify the
    reference so that fsck-cache stays happy.

I do not think the issues you are raising are solved by having that "include {hash}" thing in the commit like you propose here, instead of keeping it outside of the commit like I suggested.

What I meant to say was just I do not think having this "version dependency" in the core or outside of the core would make any difference.