Good point. You're assuming that 10 years ago you released software properly instead of just zipping up some PHP scripts and offering that for download.
You're also assuming that the person who's reviewing that old project code will dig deep enough to see how old the commit dates are. I think the GGP's advice about updating the project page is a better bet than relying on the reviewer to pick up on more subtle hints.
If the reviewer doesn't know enough about source control to fairly quickly find the most recent activity date, is it likely said reviewer is competent enough to review the source code itself, or even spend time reviewing it in the first place?
The fact that the reviewer has the technical ability to do something on your behalf does not mean he will. Specially in a weak labor market, the reviewer's job is, more likely than not, find a reason not-to-hire this particular candidate and pick the next resume on the stack.
On the other hand, think of a candidate that is able to identify a relevant piece of information, and willing to do a little extra work to display this info where the people who need it can easily find it. In my opinion, this is a sign of strong soft skills and general common sense.
Ok, fine, but if it's his job to quickly slough off imperfect candidates using minutia and minor criteria, why's he going to the trouble of looking at code in the first place?
I'd be scared if someone were to look at a codebase of component-type-X codebase with a find-fault-fast attitude, if they didn't have extensive experience in designing and building components-type-X already. It sounds like diving head-first into a Dilbert strip or DailyWTF story.
True enough. Archive formats like zip and tar preserve timestamps, but I wouldn't necessarily even trust your average power user to know how to reliably get at them.