-2

Most of the time, git can figure out when I've moved a file, but sometimes it can't. Is there a way to tell git, "trust me, this is a move?"

A key component of this is that I am using a tool to rename the file. It would be annoying to have to revert the rename and try again as a git mv, especially if other changes happened to the file before/after the move.

Daniel Kaplan
  • 62,768
  • 50
  • 234
  • 356
  • 1
    You're confusing two unrelated things. A `mv` _is_ a delete and add, and vice versa. What _you_ want to know is how Git "knows" for purposes of history that these are the _same file_. That has to do with the file's _contents_, not what command you gave originally. – matt Aug 17 '21 at 18:28
  • Ah, it's a dupe. Funny, it didn't suggest that question and it wasn't found when googling. – Daniel Kaplan Aug 17 '21 at 18:34
  • I didn't downvote, but here's a good rule of thumb: Always ask yourself, do I really really really think I'm the first person ever to wonder about this? – matt Aug 17 '21 at 18:38
  • 1
    Short answer (I had one written that says this but the question was closed) is to rename and change file content in two separate commits. [This article](https://kparal.wordpress.com/2011/08/03/git-tip-of-the-day-detect-moved-files/) explains the behavior. – codewario Aug 17 '21 at 18:38
  • @matt I thought that, googled, couldn't find the question asked, typed my question into stackoverflow, looked at the related posts, couldn't find the question asked, so I submitted this question. Of course, nobody knew I went through that process so I understand now. – Daniel Kaplan Aug 17 '21 at 18:41

1 Answers1

2

If you find a file is being added and deleted, but is really a move, it'll be detected as a move when adding both halves

However, if other changes were made to the file, it's not a move, but a normal changeset - if you want to represent the move, separate that out into another commit, perhaps by stashing the other changes away

ti7
  • 16,375
  • 6
  • 40
  • 68
  • OK, that makes sense and seems like a good practice anyway. – Daniel Kaplan Aug 17 '21 at 18:32
  • "it's not a move, but a normal changeset" meaning the previous history of the changed file is lost if I look at the history of the new name? – Daniel Kaplan Aug 17 '21 at 18:33
  • 1
    _sort of_; it'll be available, but only in the older path and not in the newer one, which is presumably what you want! you can see this with `git log -- old/path-to-file.ext` – ti7 Aug 17 '21 at 18:39
  • 1
    This is why you should move files and change the content as separate commits – codewario Aug 17 '21 at 18:39