Ramkumar Ramachandra wrote: > Jens Lehmann wrote: >> Hmm, at least the unstaged .gitmodules file has to be parsed from >> the file system. > > You seem to be touting it as a distinct advantage. To clarify what I said in a side thread: yes, as long as the submodule metadata includes the hostname I am downloading a library from, having it in an ordinary file is an advantage. The problem with URLs (and especially hostnames) is that they change. When my project's previous domain name is lost because the hosting company lost interest, I want to be able to grep for all instances of that domain name in my project's documentation and metadata and change them all at once with a simple command like the following: git grep -l -F -e oldhost.example.com | xargs sed -i -e s/oldhost.example.com/newhost.example.com/g When I clone a project with --no-recurse-submodules, I want to be able to see what other servers will be contacted when I run "git checkout --recurse-submodules". The current .gitmodules file lets me find that out with a simple, intuitive command: cat .gitmodules I might change some URLs locally, because I know that some project's upstream has moved. git submodule init git config --edit On the other hand, the single .gitmodules file will be a pain to merge if multiple branches modify it. So I do look forward to a merge strategy that deals more intelligently with its content, and wouldn't have minded a design that split this information into multiple files if we were starting over. Jonathan -- 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