4 ms·

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 tha

by iveqy 5y ago

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).

alkonaut 5y ago
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.
- morelisp 5y ago
  Of course, this is impossible in languages where file names and namespaces / structures must align. But nobody uses those, right?
  - alkonaut 5y ago
    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.
    - morelisp 5y ago
      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?
      - alkonaut 5y ago
        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.