Re: [RFC/PATCH 0/7] Rework git core for native submodules

[Jonathan Nieder <jrnieder@gmail.com>]

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