Hacker News Reader

Comment by forrestthewoods | Hacker News Reader

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.

View on HN

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.

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

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.

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.

If you use “svn mv” inconsistently, you rapidly land in conflict resolution hell (this was a nearly weekly ordeal on a former team). If you forget to use “git mv,” git still works.

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.

One of these is waaaaaay more common of an operation than the other.

The fact that it was brought up early in the article, tells us which one is a more common operation as well.

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.

Does this really work consistently? Like merging in a small java method into the middle of an existing class with a couple of methods.

Pretty sure the answer is no

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.

oh cool, I didn't know that, thanks

Reply on news.ycombinator.com