On Fri, Jul 23, 2010 at 4:31 AM, Chris Webb <chris@xxxxxxxxxxxx> wrote: > You've surely considered this already, but reading your description in this > thread, my first thought is that commits within trees could mean different > things depending on whether they're at paths listed in .gitmodules or not. > If the path is listed, the commit is in an external repository. If it isn't, > it's a reference to a local commit, allowing submodules to live in the same > repo as their parent and share some of the advantages you describe for > sub-tree. I think it would be better if we could abandon .gitmodules entirely; it's really only useful for listing repository URLs, and listing repository URLs is a major part of the problem. Something that would be neat, and at least vaguely backward-compatible would be to simply *try* fetching the linked commit objects from a remote repo, and checking them out from the local repo. If the objects exists, fetch/checkout of them will just work; if they don't, then it can (for backwards compatibility) revert to the current behaviour. Push would, if the objects exist, send them to the remote repo. Then there could be a .gitconfig option that flips this new behaviour on and off, ie. auto-checkouts subprojects that *can* be checked out without any extra knowledge, or not. If not, then you have to use the old-style git submodule stuff. (This proposal is not as easy as it sounds; to do it *right* would involve not having a separate .git repo for each subproject. That means changes to the index file format and a bunch of related stuff. Though I guess you could keep the sub-repo stuff and it would still be better than what we have now.) Have fun, Avery -- 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