What you're looking for is a "vendor branch". Assuming you want to work on this code and merge the vendor's updates with your own patches, here's how you make that easy.
git co -b vendor # create a vendor branch and check it out
That's a one time thing. The vendor branch and its ONLY going to contain updates from the 3rd party vendor. You never do work in the vendor branch, it contains a clean history of the vendor's code. There's nothing magic about the name "vendor" its just my terminology hold over from CVS.
Now we'll put the latest version from the vendor in there.
find . -not -path *.git* -and -not -path . -delete # delete everything but git files
dump the 3rd party code into the project directory # I'll leave that to you
git add . # add all the files, changes and deletions
git commit -a -m 'Vendor update version X.YY' # commit it
git tag 'Vendor X.YY' # optional, might come in handy later
We delete everything first so that git can see things the vendor deleted. git's ability to see deletions and guess moved files makes this procedure far simpler than with Subversion.
Now you switch back to your development (I'm presuming master) and merge in the vendor's changes.
git checkout master
git merge vendor
Deal with any conflicts as normal. Your patched version is now up to date with the vendor. Work on master as normal.
Next time there's a new version from the vendor, repeat the procedure. This takes advantage of git's excellent merging to keep your patches up to date with vendor changes.