.gitmodules changes with multiple git users, causing a constant headache

Question

Hello, allow me to first of all say I'm a Git n00b and relatively new to version control entirely. We've done a good job of using Git in a Windows environemnt with Visual Studio so far, and all seems to be going well. However something that is annoying is the .gitmodules 'battle' we currently have on our hands.

If UserA creates a new sub-module, the path in .gitmodules for the 'origin' will look something like:

ssh://usera@myserver/Repositories/NewModule

When I, User B, pull the changes from the server I download a copy of .gitmodules with that entry. When I try to initialize the new sub-module I inevitably cannot download from myserver, because I'm userb and hold only my SSH key for userb. I end up having to change .gitmodules to reflect my username:

ssh://userb@myserver/Repositories/NewModule

And I will end up pushing this change.

Thus we end up with a recursive problem of us both changing the username from UserA to UserB or vice versa. When either of us pull/push to the server.

Any ideas how we can resolve this issue? Maybe a shared user account for us both simply for sub-modules? Can that be done? How? Any other ideas out there, or any one that has solved this issue before?

Answer 1

One option is to install Gitosis on myserver. Everyone's clone URL would then be the same, of the form ssh://git@myserver:/path/to/repo.git. Gitosis allows you to register developers' SSH keys and allows you to specify authentication and authorization rules.

You could also roll your own by hacking ~git/.ssh/authorized_keys on myserver and doing authorization through a modification of this example update hook.

Answer 2

Other then using gitosis as gbacon said, you can change your workflow a little.

When working on public branch (branch shared with others on the team) always use sub-modules from public branch of single official repository. And instead of using your username to pull from sub-module's repository use one common user shared by the team. This user will have read-only access to the repositories.

The drawback is, if you want to push to common sub-module repository, you need to do it from another working copy using your username. That's sometimes a problem, and sometimes it's not. Depends on relation between modules and on your process.