What's the advantage of using Git submodules for Drupal core and contrib?

Question

I've seen a number of questions/blog posts about setting up a Git repository with Drupal Core and Contrib Modules as submodules, such as Setting up the ideal multiple repository Drupal Site version control with a DVCS.

What advantages do you get from this kind of repository set up?
Many people say things like "core and module updates are really easy," but what makes this approach easier/better than have a single repository containing everything for the site and using Drush to update Core and Contrib, then committing back to your repository?
I can see this being great for contributing to those projects since each module is a separate repository, but what benefits does to provide when focusing on building your own site?

Answer 1

At our workplace we avoid git submodules as they add unneccessary complexity to the system.

We run one git repo for each site, and we have drupal core as an upstream remote. This makes merging in 7.12 for example as easy as:

• git fetch upstream
• git merge 7.12

As for contrib, drush is king

• drush dl views
• git add -A
• git commit -m 'bumps views to next stable'

Hope this helps

Answer 2

Here are some of the advantages of using Git submodules with Drupal:

1. You can git fetch/merge/pull updates for your contributed modules directly from Drupal.org. There is no need to manually download a new version of each, unpack and then commit.
2. You can see upstream version history in your own Git log. This makes it easy to see where you're at; you can check if you've got specific upstream commits. Otherwise, all you can see are local changes and "Upgraded Blah from 2.3 to 2.4." log messages.
3. You don't need to reapply (cherry-pick) custom changes to your contributed modules after upgrading them. If you use the one-Git-repository method, each contributed-module upgrade will overwrite anything you're previously patched and committed. This is a huge problem because developers often forget to do the reapplying, and then you're left with resolved issues that have been reverted. If you're using submodules, you simply maintain a custom branch, and merge upstream tags (or commit IDs) into it.