That's also one way to not use version control.
Refactoring, especially renaming files, WILL make it next to impossible to find "that one bit of code you know that does the trick", because even with a rgrep or git blame it will not turn up.
As soon as the commit history is >50 commits, it's also not feasible any more to scroll through hundreds of pages of diffs.
Side note: find a way to easily store "intentionally dead" code in a file, in a way that it does not show up in the code, but can be searched at least on the commandline - easy way to get rich. Devs all over the world will love you.
(I'd imagine replacing a block of code e.g. with /* REMEMBERME /, git detecting this block (and inserting a / REMEMBER-ID 12345 */ instead), and git supporting a command like "git show-dead file.c" which shows all the dead code, too.)
It won't, if you use proper commit messages. Once you start doing that, you'll soon discover it will make everything much more discoverable. Apart from that, death to dead code! Having worked on a project where about 10 to 20% of the code was effectively dead (either simply unused, commented out, #ifdef'ed away of if( 0 )'d away) I can assure you I never ever want that again, mainly since the dead parts still turn up in every search/grep/find reference.
The technique itself is useful for debugging, but not much else.
I'd very rarely use this sort of thing, but in this case I'd say it's OK.
It's also common to include TODO, FIXME, or BUG comments into code. Sure, you can put them into issue tracker, but having them directly in code gives more context.