At Pantheon we do all our code management via
git. This lets us track operations, correct mistakes and allows a large amount of flexibility for workflows. By tracking an upstream for updates we can maintain core patches for people while providing a robust automated update functionality.
One place we do run into trouble is when there's a mix of management techniques used. If people unpack a tarball from drupal.org and check it into git (or upload it over SFTP using On Server Development), they may break their site: they'll be losing the Pressflow core and its ability to read configuration (e.g. mysql connection data) from the server environment.
Luckily, fixing that can be as easy as restoring boostrap.inc, but the legacy of adding a tarball can have other after-effects. Notably, a tarball from drupal.org contains .info files that have automatic packaging script data appended to them, like so:
; Information added by drupal.org packaging script on 2012-05-02
version = "7.14"
project = "drupal"
datestamp = "1335997555"
Drupal's core status checking code prefers this .info file data to all other sources when trying to determine its version. Moreover, the git history doesn't have any record of this, so if you wind up with legacy packaging info in your repository because of a tarball being in the mix at some point, updating via git (as Pantheon does) will leave you with updated code, but a Drupal installation that is mis-reporting its own version based on out-dated packaging information.
This is annoying (and common) enough that we wrote a quick PHP script to help clean it up. If you want to remove this cruft release packaging text from your core files, you can run the following on an up-to-date git clone of your codebase:
You can snag the script (or suggest improvements!) from the GitHub gist.
Pantheon's code import tools don't suffer from any of these problems — we run a heuristic to determine the imported major/minor version, rebase on Pantheon's upstream, and then bring the site up to date. This situation still arises whenever core updates come out though, or as the result of some complex or work-around-y manual imports.
Hopefully this helps some of our users, or other Drupal developers looking to move to a purely git-based workflow!