2

I moved a couple of files that are in my project, but I did the move inside finder on my mac. I see that git source control treated the files as an add.

I haven't done a commit yet. git status shows the following:

  • Under Changes to be committed, the updated/moved files are listed as new files
  • Under the Changes not staged for commit, the updated/moved files are listed as modified, the original files are listed as deleted.

Now when I do a version compare with these files in Xcode, the viewer has no history.

I looked at the accepted answer here and tried git log --follow ./pathtomynewfile. That gave no result.

Viewing changes in the version editor has become a valuable tool, and I would like to continue under these circumstances.

What can I do to tie to old version history to the new, relocated version?

Community
  • 1
  • 1
Jim
  • 5,940
  • 9
  • 44
  • 91

5 Answers5

3

Git won't necessarily show something as a "move" until after you've made a commit. This operation is not identified when the commit is done, but is done after the fact by tools (such as git log --follow). Basically, when Git tools see that a new file has appeared in the history, it looks around for other files that it might have come from (if the same or similar file was deleted in the same commit, then Git calls it a move).

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
  • 1
    I did the commit and then looked at the history. They still were not tied together. I then tried git log -- follow. That looked like it tied back to older commits, but it doesn't seem to have recreated any persistent relationship that I can see in my version editor. – Jim Aug 10 '12 at 01:45
  • There might be a flag you have to turn on in your version editor (XCode) that follows through renames. I'm not familiar with the Git support in XCode so I'm afraid I can't point to the correct bit. – Greg Hewgill Aug 10 '12 at 01:57
  • 1
    Unfortunately, it seems that there's no such flag in Xcode. Maybe it can be done through a hack, but I have not figured it out. It would be great if Apple updated the default Git behavior to use 'git log --follow' rather than just plain 'git log'. – Ricardo Sanchez-Saez Oct 07 '12 at 18:08
2

Either use git mv, or git add the new file, and git rm the old file. Both add and rm need to be in the index when committing, otherwise git does not recognize it as a rename.

user1338062
  • 11,939
  • 3
  • 73
  • 67
0

Roll back the change, and then use

git mv

That way, your files will be moved, and git will keep track of the move, preserving file history.

Yusuf X
  • 14,513
  • 5
  • 35
  • 47
  • 3
    That's not how Git works. It is not required to use `git mv` in order for Git to keep track of the move, it works equally well with an add and a delete. – Greg Hewgill Aug 09 '12 at 07:20
  • You're right it's usually not required, but on occasion I've found that my changes confuse the git status, and git mv clears it up. – Yusuf X Aug 09 '12 at 07:34
0

It is very likely that git will show the move as a delete and an add. Git does this when you move the file outside of git.

The result is the same.

Kao
  • 2,242
  • 3
  • 22
  • 31
-1

You can go to the previous stable version of the code in 3 steps:

  • Using git staging view, remove all the staged files. (I don't know how to open it under mac)
  • run git reset --hard HEAD It will reset your all local uncommitted changes, but won't delete newly added files which are not yet added to the git yet
  • Now, Manually delete all the new files shown in git staging view.
chirag
  • 172
  • 7