Hacker News Reader

Comment by pansa2 | Hacker News Reader

> The commit was about 10 years old, and it replaced every tab with 4 spaces.

Reminds me of a project I worked on a while back - whenever you looked at the git history of a file, if you went back far enough you’d hit a dead end at the point where every source file was renamed from *.c to *.cpp.

View on HN

—follow

We have a few files at work that change name with every commit…

Git tracks changes across renames though right?

I think git can be convinced to see a rename as a delete followed by a file creation.

Not really. Git tracks content and not files. File renames doesn't exists in git. When git tell you that a file is renamed it's because an algorithm guesses that a file is renamed (if the content is similar).

Exactly, so any rename should be done without other edits in the same commit, so the content hashes exactly the same. Any bulk rename in a repo would satisfy that and be a non-issue.

Of course, this is impossible in languages where file names and namespaces / structures must align. But nobody uses those, right?

Even in those you would rather rename first then fix it in a subsequent commit, and just accept that the intermediate state isn’t correct.

Why is having an obviously-incompilable intermediate state in your history a good idea, rather than using a diff algorithm that will find the move anyway?

Not sure I follow. So long as git understands the move so a single file history (using the standard command or standard IDE tooling) doesn’t “stop” before the rename, then I’m happy. And I’m very happy to accept one commit in the history that doesn’t build in order to get that.

yes

Reply on news.ycombinator.com