5 ms·

>if you want to reliably record file moves during refactors in git, you should do two commits: the first commit just moves the file without any changes, the sec

>if you want to reliably record file moves during refactors in git, you should do two commits: the first commit just moves the file without any changes, the second commit applies all the required fixups. Yes this will record a file move in one of the commits but if you diff between before and after the two commits a file move might not be shown. When thinking about file moves in git it is worth remembering this comes from the diff tool not from the commits since the commits just show the state of the file system at the point it is committed.

forrestthewoods 3y ago
The fact that Git is incapable of effectively tracking files across moves is such a failure of Git. It’s critical information that ought to be robustly tracked.
- Izkata 3y ago
  The flipside is when two files are combined, git blame can track history across both sources. Can't do that when explicit moves are recorded, one of the source files would be recorded and the others treated as new lines.
  - forrestthewoods 3y ago
    One of these is waaaaaay more common of an operation than the other.
    - vinnymac 3y ago
      The fact that it was brought up early in the article, tells us which one is a more common operation as well.
      - Izkata 3y ago
        Moving single functions or groups of lines (like extracting something common into a function) I'd say is more common than even that, and this same functionality tracks those changes across files too.
  - mnsc 3y ago
    Does this really work consistently? Like merging in a small java method into the middle of an existing class with a couple of methods.
    - cerved 3y ago
      Pretty sure the answer is no
      - Izkata 3y ago
        That's what the -C flag is for, to make it more/less sensitive. So answer is "yes, if you use it", and this is what it looks like: $ git blame file3 -C1 9afddd5e file3 (Izkata 2024-01-01 11:40:51 -0600 1) 9c8635a7 file2 (Izkata 2024-01-01 11:40:27 -0600 2) 4 9c8635a7 file1 (Izkata 2024-01-01 11:40:27 -0600 3) e 9afddd5e file3 (Izkata 2024-01-01 11:40:51 -0600 4) Also fun fact, -C can be given up to 3 times: 1 - Look for the source in files modified in the same commit 2 - Look for the source in any file that existed as of that same commit 3 - Look for the source in any commit Great for if you suspect the original committer didn't do the delete/add (move) in one commit.
        cerved 3y ago
        oh cool, I didn't know that, thanks
- IshKebab 3y ago
  I dunno, it kind of makes sense. If you do just rename a file it can track it. If you do more than renaming, it immediately becomes ambiguous as to whether you actually renamed the file or just deleted it and made a new very similar file. Or multiple similar files. I think the real failing is that it isn't very good at handling the "rename and slightly modify" case, even when it theoretically could. Of course it's non-trivial to detect that case, and there are flags you can use to improve the detection but it's still not great in my experience. It might make sense to allow adding hints to the git commit message to help it. Dunno if anyone has tried implementing that.
  - Karellen 3y ago
    I think GP's point was that there is an argument that `git` should be able to track "real" metadata about what changed. e.g. `git mv foo bar` should be able to record that "foo" was definitely renamed to "bar" - even in the presence of massive changes. Whereas `git rm foo; git add bar` should be able to record that "foo" was deleted and "bar" was added, even if the files are substantially similar. And that this should be more meaningful to `git` itself than just hints in the commit message. (Personally, I've not come across the need for such a feature. But I can understand why people might want to have it be available.)
    - IshKebab 3y ago
      Yeah it sounds nice in theory but the number of edge cases and complications it adds are crazy. * You need to add `git cp`. * You'll mess things up if you accidentally `mv` instead of `git mv`. * All IDEs have to add support for this. * Have fun resolving metadata merge conflicts! That's just the things I thought if in a few seconds. IMO the sensible way to improve this is to have a place for Git to add hints, so that it's automatic rename detection algorithms work better.
      - forrestthewoods 3y ago
        I think you’re overcomplicating it. Files just need to know where they moved from, if anywhere. Copy, modify, delete operations can be auto-detected almost all of the time. Lineage can be edited after the fact if needed.

forrestthewoods 3y ago

The fact that Git is incapable of effectively tracking files across moves is such a failure of Git. It’s critical information that ought to be robustly tracked.

Izkata 3y ago
The flipside is when two files are combined, git blame can track history across both sources. Can't do that when explicit moves are recorded, one of the source files would be recorded and the others treated as new lines.
- forrestthewoods 3y ago
  One of these is waaaaaay more common of an operation than the other.
  - vinnymac 3y ago
    The fact that it was brought up early in the article, tells us which one is a more common operation as well.
    - Izkata 3y ago
      Moving single functions or groups of lines (like extracting something common into a function) I'd say is more common than even that, and this same functionality tracks those changes across files too.
- mnsc 3y ago
  Does this really work consistently? Like merging in a small java method into the middle of an existing class with a couple of methods.
  - cerved 3y ago
    Pretty sure the answer is no
    - Izkata 3y ago
      That's what the -C flag is for, to make it more/less sensitive. So answer is "yes, if you use it", and this is what it looks like: $ git blame file3 -C1 9afddd5e file3 (Izkata 2024-01-01 11:40:51 -0600 1) 9c8635a7 file2 (Izkata 2024-01-01 11:40:27 -0600 2) 4 9c8635a7 file1 (Izkata 2024-01-01 11:40:27 -0600 3) e 9afddd5e file3 (Izkata 2024-01-01 11:40:51 -0600 4) Also fun fact, -C can be given up to 3 times: 1 - Look for the source in files modified in the same commit 2 - Look for the source in any file that existed as of that same commit 3 - Look for the source in any commit Great for if you suspect the original committer didn't do the delete/add (move) in one commit.
      - cerved 3y ago
        oh cool, I didn't know that, thanks
IshKebab 3y ago
I dunno, it kind of makes sense. If you do just rename a file it can track it. If you do more than renaming, it immediately becomes ambiguous as to whether you actually renamed the file or just deleted it and made a new very similar file. Or multiple similar files. I think the real failing is that it isn't very good at handling the "rename and slightly modify" case, even when it theoretically could. Of course it's non-trivial to detect that case, and there are flags you can use to improve the detection but it's still not great in my experience. It might make sense to allow adding hints to the git commit message to help it. Dunno if anyone has tried implementing that.
- Karellen 3y ago
  I think GP's point was that there is an argument that `git` should be able to track "real" metadata about what changed. e.g. `git mv foo bar` should be able to record that "foo" was definitely renamed to "bar" - even in the presence of massive changes. Whereas `git rm foo; git add bar` should be able to record that "foo" was deleted and "bar" was added, even if the files are substantially similar. And that this should be more meaningful to `git` itself than just hints in the commit message. (Personally, I've not come across the need for such a feature. But I can understand why people might want to have it be available.)
  - IshKebab 3y ago
    Yeah it sounds nice in theory but the number of edge cases and complications it adds are crazy. * You need to add `git cp`. * You'll mess things up if you accidentally `mv` instead of `git mv`. * All IDEs have to add support for this. * Have fun resolving metadata merge conflicts! That's just the things I thought if in a few seconds. IMO the sensible way to improve this is to have a place for Git to add hints, so that it's automatic rename detection algorithms work better.
    - forrestthewoods 3y ago
      I think you’re overcomplicating it. Files just need to know where they moved from, if anywhere. Copy, modify, delete operations can be auto-detected almost all of the time. Lineage can be edited after the fact if needed.