Linus Torvalds wrote: > I don't dispute that a new link object might be a good idea, but > there's no explanation of the actual format of this thing anywhere, > and what the real advantages would be. A clearer "this is the design, > this is the format of the link object, and this is what it buys us" > would be a good idea. Yeah, I need help with that. I've just stuffed in whatever fields popped into my mind first. The current ones are: 1. upstream_url: this records the upstream URL. No need to keep a .gitmodules. 2. checkout_rev: this records the ref to check out the submodule to. As opposed to a concrete SHA-1, this allows for more flexibility; you can put refs/heads/master and have truly floating submodules. 3. ref_name: this specifies what name the ref under refs/modules/<branch>/ should use. 4. floating: this bit specifies whether to record a concrete SHA-1 in checkout_rev. 5. statthrough: this bit specifies whether git should stat() through the worktree. We can turn it off on big repositories for performance reasons. > Also, one of the arguments against using link > objects originally was that the format wasn't stable, and in > particular the address of the actual submodule repository might differ > for different people. So when adding a new object type, explaining > *why* the format of such an object is globally stable (since it will > be part of the SHA1 of the object) is a big deal. After some discussion, I hope to be able to finalize a list of fields that will suffice for (nearly) everything. -- 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