Projects A and B both use library project L:
Judging by what people have written about it on the web, managing this situation appears to be a headache:
http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/
why you shouldn’t use Mercurial subrepos
Are there any solutions out there that avoid difficulties such as:
• Losing work because the VCS did something unexpected
• Hellish subrepo merges
• Screwups caused by the VCS pointing to an unexpected version of the submodule,
frequently made worse because the user didn’t realize that had happened
2
There is absolutely no reason to avoid git submodule; it works far better than most of the alternative “solutions”. Just have your build script assert (but not modify; to solve problem 1) that the submodule is present and up-to-date (solves problem 3), and only make changes to the submodule as its own repo, not as if it’s part of the main repo (solves problem 2). I’ll repeat that: only make changes to the submodule as its own repo.
Additionally, recent versions of git supply git submodule update --remote to automatically pull the latest version from the branched you’re tracking.
Assuming you are not completely ignoring the most important git command of all time, git status (whose output is also included in the editor when you run git commit), you won’t have any problems.
Of course, if you’re using some GUI frontend, it’s probably crap, but that’s true whether you’re using submodules or not.
2