6 ms·

> 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

by pansa2 5y ago

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

iveqy 5y ago
—follow We have a few files at work that change name with every commit…
deleted 5y ago
[deleted]
alkonaut 5y ago
Git tracks changes across renames though right?
- rocqua 5y ago
  I think git can be convinced to see a rename as a delete followed by a file creation.
- 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.
- cerved 5y ago
  yes

6 ms·

> 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

by pansa2 5y ago

iveqy 5y ago
—follow We have a few files at work that change name with every commit…
deleted 5y ago
[deleted]
alkonaut 5y ago
Git tracks changes across renames though right?
- rocqua 5y ago
  I think git can be convinced to see a rename as a delete followed by a file creation.
- 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.
- cerved 5y ago
  yes