In CVS we use vendor branches to track upstream sources in our tree. The vendor branch commit automatically “merges” updates to files we haven't touched in our HEAD branch, and leaves any conflicts to be handled in a later commit.

The vendor branch feature was largely necessary for CVS, which makes dealing with branch merges difficult. The process I would expect for our first FSF vendor branch update for gcc in git would be something like:

git-checkout master # 1
git-pull -s ours . FSF # 2
git-checkout FSF # 3
cd contrib/gcc
git-rm * # 4
tar -whatever ~/new-gcc.tar.gz
git-add * # 5
git-commit
git-checkout master
git-pull . FSF # 6

1. You're on the master branch
2. Create a commit with no changes and a parent including FSF, to mark that all merges from FSF are already done.
3. Switch to the vendor branch.
4. Remove the set of files from the last version from the vendor.
5. Add the new set of files. Now, the index is updated with all the new gcc code. Note that files that didn't change between 4) and now won't be considered updated.
6. Merge the new changes from the vendor branch. This should basically apply the diff between the last version of gcc and this one. The merge may fail if there are actual code conflicts, but this is more rare than with CVS.

And for later vendor branch updates, you would skip the first two steps. Note that I haven't tested this exact set of commands, so I may have made mistakes in typing.