Re: [RFC] Support projects including other projects

DB> My reasons for having it in the core are as follows:

DB> - All of the porcelain layers have to, at least, agree as DB> to how this is represented in order for repositories to be DB> portable; since the representation is common, it might as DB> well be core.

That is weak. .git/refs/heads/master is not core, but something Porcelain need to agree on [*1*].

DB> - There are currently no special files which are tracked for cogito (et DB> al) to put the information in.

I am somewhat sympathetic to this, but then there are probably lot other things that are more relevant than this "required version" thing. One thing that immediately comes to mind is the dontdiff list. Also, if you consider Cogito and GIT independent projects as you said, you would probably need to have "require {project-name} {commit-id}", not "include {commit-id}". Things start smelling much more like the traditional package version matching issue which is outside of SCM (let alone core GIT).

DB> - Ideally, the dependancy would only be per-commit, not DB> per-tree; if Petr releases a new cogito which only merges a DB> new mainline with the git-pb, the cogito tree object should DB> be the same (since the cogito content didn't change). This DB> means that it can't be anywhere other than the commit.

As I already said, I consider the current "overlayed" directory structure broken and not worth considering the toolset support [*2*].

DB> - If the solution to the issue of finding the necessary DB> git-pb is to store it with cogito, then the programs that DB> pull from this repository need to know that they need to DB> pull the git-pb portion, and fsck-cache needs to know that DB> the cogito references the git-pb.

I do not think this is necessary for the same reason as I dismissed the third point above.

[Footnotes]

*1* I consider git-pull-script one example of Porcelain, JIT knows about it as well.

*2* "Broken" is probably a too strong word here. I know Petr did it that way because it was the simplest way to start, and I started the same way when I started JIT, until I realized separating the core and treating the core as something I can borrow from the neighbouring directory is much easier to manage. I think Petr knows this, and I further think that is why he started git-pb.