re run git file comparison algorithm

I moved all my files into a folder ignored by git (an over-zealous .gitignore). When I fixed the problem in .gitignore I had a set of deleted files and a set of new untracked files - even though most of the files are identical. How do I ask git to re-run its comparison algorithm to properly track changes in these files?

Summery of what I typed:

mkdir ./libs
git mv ./src-code ./libs/src-code #I might just have used mv
#a few changes
git status 
# nothing changed, huh?
# oh, I am ignoring all libs directories in .gitignore, 
#   I meant to only ignore the one at the root - fixed
git开发者_运维技巧 status
#   deleted:    ./src-code/...
# Untracked files:
#       ./libs/src-code

git mv doesn't actually anything you can't do without it, because git doesn't really have a concept of "a move" at most levels.^† For the most part moves are represented in git as an added-file / deleted-file pair, which git may detect and treat as a move when displaying a diff or updating the working tree. [From your question, it looks like you already know this, but just for completeness...]

One consequence of this is that it's totally fine to use normal non-git mv (or any other tool) to move git-controlled files around; the results won't be any different (and this can be handy if, for instance, you want to use some special tool to do the moves).

However, as with any change to your working tree, git doesn't really "know" about it until you've added the changed thing to the index with git add.

So git mv A B is just a convenience command roughly equivalent to mv A B; git add -u A; git add B; since you already had done the mv, you could have just used git add in the same way to tell git about the new and deleted files. An easier way, if it's ok for other changes in your working-tree to be put into the index, would just be git add -A, which adds both new files and changes in the working-tree (including deleted files) to the index.

[That's usually what I do: mv A B; ...more changes...; git add -A; git commit...]

────────
^† This is different than many other source-control systems, which may have an explicit notion of moves that's stored in commits, etc.

When I have this problem, it's because I've mved instead of git mved. Try just mving them back, then git mving them where you want them.

git mv is a rather excessive solution. Simply git add libs/src-code and then git commit -a. git will detect the rename.

That said, it's usually nicer for humans if you make the rename its own commit.