Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > On Wed, 27 Sep 2006, A Large Angry SCM wrote: > > Wouldn't an fsck in the parent complain about missing objects? > > ... not if my original idea (which I might have forgotten to mention ;-) > was implemented: symlinking subproject/.git/objects to .git/objects. Right. Which is one of the truely wonderful things about symlinks in .git/refs and symlinking .git/objects. :-) I don't know about anyone else but this thread has certainly helped me rationalize a few thoughts about "subproject" support. The major things I've taken away from it are: - Subprojects of any reasonable SCM should be supported. Although this is Git we sometimes want to play nice with other people working in the same pond. We have a historical track record of doing this when it makes sense (git-svn, git-cvsserver, etc.) but clearly doing it for every SCM out there is not possible. But that said having "out of the box" support for Git subprojects within a larger Git project should Just Work. It doesn't really yet. - Higher level projects should drive subprojects. Higher level projects tend to be composed of specific revisions or specific generations of subprojects. Part of the content of the higher level project is just what those subproject specifications are and how those subprojects should appear in a working directory. - Git Porcelain should help the user. Git operations should translate down through lower level projects when possible, and lower level project changes should push up when possible. E.g. git-fetch in a higher level repository should percolate down into the lower level repositories automatically. Ditto with git-checkout and probably git-push. git-commit in a lower level repository probably should update the specification file(s) in the higher level repository but not commit the higher level repository. - The subproject SCM interface needs to be modular. Users need to include many different subprojects and not all of them use Git. Ideally Git would be able to at least be easily taught by the user how to invoke a particular subproject's SCM for the purpose of an initial checkout, if not for additional operations such as pull, push, commit and tag. I used the term "generation of subprojects" as not everyone wants to bind their root project to a specific revision of a subproject. Indeed that may not be entirely practical. Instead just a particular lineage of development (e.g. "Version 1.0" vs. "Version 1.2") may be all that is needed. For example including a CVS hosted subproject into a larger Git project means you can't use a specific SHA1 to reference a single version of that CVS subproject. Yet you can use a CVS branch or label name. But both of those are moving targets in a CVS repository. But in a sane CVS project a label or a branch will be relatively stable over time, meaning that its good enough given that its all we got (without importing everything into Git anyway). Likewise a Git project including a Git subproject should be able to reference a named tag of the subproject. If the subproject changes its tag and the fetcher agrees to the change (with a --force) then its OK for the subproject to follow that tag change. Likewise it should be acceptable for a subproject to reference a specific branch head. Although this is a moving target that may be acceptable while the higher level project is under rapid development. However an annoted tag probably should not be able to be created on the higher level project unless all lower-level subprojects are referenced by tags (or the equivilant) in their SCM. Which implies using a "stable tag" in CVS, a "/tags/foo@rev" in SVN, or an annotated tag in Git and updating the specification file(s) to reflect that. -- Shawn. - To unsubscribe from this list: 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