This seems to say that all submodules have to be named '/repo/modules/something' which isn't very flexible. Am I missing something?

The path here is actually: [server's gitdir]/modules/[submodule-path], so, for example, to point to the restbase submodule the remote url is: http://tin/deployment/restbase/.git/modules/restbase

This is the submodule's gitdir path as of git 1.7.8 (tin is on 1.7.9): https://github.com/git/git/blob/master/Documentation/RelNotes/1.7.8.txt#L109-L114

In testing I found that, while a local submodule clone will obey a submodule .git file's gitdir: [path], a remote http submodule clone just complains that [submodule/path]/.git/ is not a directory. As such you have to update the remote's submodule path to point to the location of a submodule's actual git directory at [parent gitdir]/modules/[submodule-path]

Can we make this optional? There might be situations where it makes more sense to pull from gerrit (or eventually phabricator) instead of tin.

One possible solution to avoid such repetition in tasks.git_* (logger, user, location etc.) and actually a lot of other tasks functions would be to introduce a basic Command or Proc class/module that encapsulates the command string, executing user, child logger, etc. There was actually a lot about checks.CheckJob and checks.execute, namely the event-loop schedule/run/poll/wait execution pattern, that I thought could live in such a module as well.

Anyway, I'm of the same mind: it's something to think about for future refactoring but not a blocker of current work.

We just want to process one level of submodules but won't this will process all .gitmodules files recursively?

Just throwing out a straw man here but since you're strip()-ing below, you might want to just split on '='. That would catch edge cases where someone might have manually modified the .gitmodules files and used no spaces (which I think is still technically valid as far as git is concerned).

I like the idea of a command / process class, and in fact I've implemented (badly) something like that in iscap. The reason for the abstraction in iscap is that I want to support executing regular shell subprocesses as well as python cli.Application instances, where the python commands can potentially run in-process instead of via the shell. The same abstraction would be really nice for remote commands which could have a local instance to represent the remote execution, making the code a lot more consistent and seamless (the remote execution would be completely abstracted away from the high-level logic)