2

In a git working tree, I have a file "foo". I have made significant modifications to this file, then renamed it to "bar". Git detects this as a deleted/new file. According to this answer, in order for git to detect that they are the same file, the move should be committed first, then the modification. Given that the file is already modified and moved (but not yet staged or committed), what is the procedure to follow to commit the move operation first, then the modification (ensuring I don't lose my modifications in the process)?

Similarly, what is the procedure to do this if the move/modification has already been committed in a single commit?

tvStatic
  • 921
  • 1
  • 9
  • 26

1 Answers1

7

Honestly, the safest thing to do is to:

$ mv bar bar.safe   # move bar someplace safe
$ git checkout foo  # get the old copy of foo
$ git mv foo bar    # tell git about the move
$ git commit -m 'I moved foo to bar'
$ mv bar.safe bar
$ git add bar
$ git commit -m 'But bar is totally changed now'

and the safest this to do if the move/modification has already been committed is to undo the commit (in default --mixed mode, to change the index but keep the working directory as-is):

$ git reset HEAD^

and then use the procedure above.

You can technically use git update-index to directly manipulate the index independent of the contents of the working directory (see the --cacheinfo argument), but I think the above method is more straightforward.

K. A. Buhr
  • 45,621
  • 3
  • 45
  • 71