Git stores the files as so-called blob objects, they're prefixed with a simple header. So even if sha1(file1)==sha1(file2), your git will still get different hashes, because it's doing sha1(prefix+file1), sha1(prefix+file2). You'd need a file that collides with this prefix. This is certainly possible, but not sure if it may mean you need to pay for that several thousand cpu/gpu cluster google used to make it feasible. Maybe there are precomputations that can be reused somehow.
Why wouldn't the header be the same? The files have the same size and same name here? Does it have anything to do with zlib compression (I'd imagine the two files compress differently since they are actually different?)
Even if you use exactly the same headers it means that at the moment the SHA1 algorithm encounters the specially crafted data that creates the collision it's in a different state than with the "naked" files, so the collision (very probably) won't happen. Adding more content at the end of the file would work though, since at this point the SHA1 state machine would be in the same state on both sides.
You can test that easily with the files provided:
$ sha1sum shattered-*
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf
$ echo 'more content at the end' >> shattered-1.pdf
$ echo 'more content at the end' >> shattered-2.pdf
$ sha1sum shattered-*
42cfb194d7e7d557c00d9f2c8d590641ee8f871c shattered-1.pdf
42cfb194d7e7d557c00d9f2c8d590641ee8f871c shattered-2.pdf
$ echo 'more content at the start' > other-1.pdf; cat shattered-1.pdf >> other-1.pdf
$ echo 'more content at the start' > other-2.pdf; cat shattered-2.pdf >> other-2.pdf
$ sha1sum other-*
ed2ab5fc6c7109a7c7da13fdc05585e4d9e4fe0c other-1.pdf
a41e3539ca0e317a4097bb26ae978e79119d09c8 other-2.pdf
True, but the attack already builds upon modifying the state machine to get the same end result, creating data to allow for a specific prefix (e.g. always getting the desired intermediary state) should also be doable in some form of this attack.
Would it help if we padded the prefix so that the rest of the files are aligned to the block size of SHA1 (512bits), so that the crafted blocks are still block-aligned? Or does the different initial state (due to a different prefix) break any chance of re-colliding with these specific files? (i.e. you'll have to run the full brute force attack again with a valid git blob header as a common prefix?)
