Re: [RFC] Support projects including other projects

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

>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:

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.