Of course, that only gives you about 40 bits to play with (assuming the further you move the timestamp, the easier it is to detect) so it wouldn't be completely sufficient on its own.
Thankfully most source code is plain text. There are mostly trivial ways to encode information in whitespace/etc, but again, the ability to carry some useful information AND commit a SHA1 collision is currently non-trivial. Plus Git has specifically put in some hardening for the existing SHA1 hashes to make this even less feasible in the particular application of a git repo.
A pipe wrench to the back of the head(or social engineering) of some random committer is probably a LOT easier to accomplish.
That said, if your primary nemesis is one the giant nation states(US, China, Russia, Etc) AND you were very high target for them, then all bets are off, as they can pretty much accomplish whatever they want against any individual/small group on the planet. I would imagine most of us are not even remotely in this situation.
a) you can definitively generate content that will be hashed to the same value - this is a given since anything that compresses a source into a much shorter representation allows that by definition (lets ignore feasibility/time/cost)
b) Making a) in a way that the contents are usable for a given purpose, doesn't introduce severe noticeable changes, and plays ball with the remaining stuff (OS, build chains, the context where it's included in, etc) seems to be the actual difficult part
So my conclusion was at the time that in terms of feasibility it's probably easier to hack the chain itself replacing the hash. But again, if there's a master "hash" for whatever artefact is produced that relies on all those hashes it would also need to be replaced?