I'm getting quite fed up fiddling with those foreign_ident markers.
A serious problem is that the changes in .gitattributes makes it cumbersome to cherry pick patches between branches and reorder commits (before push, of course). The .gitattributes diffs also preclude the possibility for git to recognize the same patch on the different branches.
Another annoyance is that the commit checks get in the way: I never remember to check for foreign_idents before committing, so the commit get interrupted and I have to salvage the commit message (which in the case of using MaGIT in Emacs is definitely lost). Often it's also necessary to reset the file to get the $Id$ expansion right, which means I have to restage the commit with chunks and everything.
On top of that there's various strange behavior in git with "spook differences" when the $Id$ handling changes. E.g. today I got into a state with a file where git reset/checkout resulted in it being considered changed in the $Id$ expansion right from the start. Killing the chunk didn't work, and it simply wasn't possible to get the working tree clean with the intended git tools. Things like this are bugs in git, but be that as it may, they add to the frustration.
This foreign_ident system is very proper and correct, but it's frankly a big PITA, and I don't see any benefits with it that even comes close to make it worth the hassle. Keeping the cvs idents around in the historical versions is one thing, but replacing them gradually instead of wholesale is just a little more neat, perhaps. The whole thing boils down to avoiding just a single extra commit.
I don't think it's a passing phase either - there are a lot of files, and it'll take a long time for them all to change naturally (it'll probably never happen). Also, the problem with backporting patches will only get worse as the current branch loses more foreign_idents compared to the old ones.
So is there a compelling reason to keep those foreign_ident around, or would it be ok to drop them all in one go?