Jakub Narebski wrote: >>It would still support that. Each commit to the sub-project involves a >>change to the tree of the "main" commit line (a copy of the commit into >>a sub-directory of it). The advantage is that the "tree" in the main >>commit is the combined tree, you don't need to treat the case specially >>to just get the contents out. >> >> > >As far as I understand, for subproject commit "bind" link (and perhaps the >keyword/name "link" or "ref" would be better than "related") point to other >subprojects commits (trees), while the Sam's "prior (3)" example link would >point to the toplevel project (gathering all subprojects) commit, and it >would probably be named/noted "toplevel", not "prior". > >Am I correct? > > I don't think you quite get my meaning. What I'm saying is that with the right kind of general purpose relation between commits, you don't need "bind" at all. Firstly, you would have your sub-project as its own commit line. That is a fairly straightforward thing. Secondly, the project that includes it has a corresponding commit for each commit on the sub-project. This commit changes the portion of the outer project's tree where the sub-project is bound. This means that you don't need to understand this "bind" relation to be able to extract the tree, and keeps the model simple at the expense of an extra tree object or three per commit. It also does not restrict the manner of the "binding", porcelains or users are free to do it selectively, for instance. Actually there is large similarity to this and cherry-picking. In essence you're cherry picking every single commit from a different commit heirarchy, except that you are applying the patches into a sub-directory. Sam. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html