2

I reset the top of my local git branch. In that check-in I moved a file using git mv, now it shows that the file has been removed and the file is located in the untracked file list.

If I readd the file and check it in, will it think that it's a move or just a delete and a newly added file? If so, how would I easily move it? Do I have to move the file back to its original location and then do a git mv again?

Adrian
  • 10,246
  • 4
  • 44
  • 110
  • Git won't "think" anything because Git actually doesn't store whether a file is added, deleted, or renamed (moved). Each commit stores a snapshot of all the files and their contents for that commit. It's only when you compare 2 commits that Git shows you whether it thinks a file is added/deleted/renamed. Adds and deletes are straight forward, and the logic it uses for renames is configurable meaning sometimes it may show as a rename and other times it won't. – TTT Dec 07 '22 at 19:55
  • Doesn't a `git mv` explicitly tell `git` to think of this as a rename @TTT? – Adrian Dec 07 '22 at 19:56
  • No. `git mv` is just a shortcut which is equivalent to you manually moving the file (outside of Git), and then staging both the delete and the add. – TTT Dec 07 '22 at 19:57
  • Huh. That seems counter intuitive @TTT. But I guess if there are very little changes between the actual file contents, `git` would get it right most of the time. – Adrian Dec 07 '22 at 19:59
  • I agree it's counterintuitive (it was initially for me as well), at least until you learn that Git doesn't actually store renames. Anyway, it appears that even though you used `git mv`, it seems like the add portion of that command didn't happen for some reason, which is probably how you ended up where you are now. Regardless of what happened, if you add it back in the *new* location (and either amend if it's still the top commit, or squash it into the commit that deleted it), you'll end up where you want to be as if the `git mv` staged both changes initially. – TTT Dec 07 '22 at 20:03
  • Note there are some caveats to my general statement about what `git mv` does. [Further reading here.](https://stackoverflow.com/q/1094269/184546) Some of the answers and comments over there show some minor differences. – TTT Dec 07 '22 at 20:11
  • @TTT. Seems that a `git mv old_name new_name; git commit` vs `mv old_name; git rm old_name; git add new_name; git commit` does work differently as if I then do a `git diff @^..@`, the 2nd `git` says a file has been deleted and a new one has been added. They have nothing to do with each other. However, the 1st says that they are related and shows a diff as if they were the same file, just modified. Maybe the new versions of `git` are acting smarter? Running `git version 2.38.1.windows.1`. – Adrian Dec 07 '22 at 21:32
  • Hmmm, something doesn't seem right there. I wonder if you can come up with a minimal reproducible example for this? – TTT Dec 07 '22 at 21:37
  • No. I was wrong. I had done a `git mv; git commit;` but had not committed the actual changes. Then did a `git diff` and it showed the diff between the non-staged file and the file that was moved. They do seem to be equivalent @TTT. I wish that git maintainers would really fix this because it makes it difficult do a diff between files that are related but have been edited and moved. – Adrian Dec 07 '22 at 22:56
  • Ok, so I read [Linus's reasoning](https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/) for why not to track files, which is valid. However, in that case, it is `git`'s search functionality that is lacking. His _superior_ algo _still_ isn't implemented in `git`, and why not? Is it because it'll take more CPU cycles? If so, then have a switch to say, "I don't care about CPU cycles". The problem is _still_ with `git` and _still_ should be fixed. – Adrian Dec 07 '22 at 23:30
  • There are ... some *pieces* of this "superior algorithm" in there, in Git: you'll find bits of them in `git blame` for instance. But it's not all put together the way it needs to be. When will it ever be? Who knows? – torek Dec 08 '22 at 08:37

0 Answers0