1

I'm having trouble googling the solution to this problem by describing the symptoms, so I'm assuming I'm not using the correct terminology. Here's what I did:

  1. Trying to reorganize my git file structure a little, I moved fileA from repo-root/ into repo-root/subfolder/ in nautilus.
  2. $ git add .
  3. $ git commit -m "Just moving files"
  4. $ git push

Looking at github, I see the file is now located in both repo-root/ and repo-root/subfolder. Oh no, I only want one copy in the repo! No problem, I can pull the repo again and git rm the file in repo-root/.

\5. $ git pull Already up to date

Uh oh.

The file doesn't exist in that location on my local machine, so git rm fileA in repo-root/ doesn't see the file when I tab over. I also can't seem to pull it down without maybe entirely re-cloning again? What is the name of the state my repo mismatch is in, and how do I fix it?

Mittenchops
  • 18,633
  • 33
  • 128
  • 246
  • possible duplicate. Just use `git rm` to remove files (see http://stackoverflow.com/questions/1767999/git-and-removing-files)? bash completion won't work in that case. Also you can use `git checkout filename` to restore file (see http://stackoverflow.com/questions/6407379/how-to-bring-back-removed-file). – alex vasi Mar 06 '13 at 15:21
  • I understand this has the same answer as probably a thousand other git questions---but it's a different question. I want to know the /name/ of the condition I'm in. If I google "git and removing files" I still don't get the link you posted, even though that's the title. Also, there are a thousand other issues related to "removing files" that also pop up for a query that general. – Mittenchops Mar 06 '13 at 15:28
  • 1
    condition... hmm. "Modified working tree" probably that is. You just deleted a file from your working tree. That is all. `git status` should report to your that file as deleted and suggests to add it or restore, with commands examples. – alex vasi Mar 06 '13 at 15:36

1 Answers1

0

Hmm, seems solution is...

  1. git rm fileA still works, even though there is no longer a local copy to auto-complete---you have to know the name of the file. This worked for me, but could be trouble if you had a large number of files to remove.
  2. git add -u will delete stuff staged for deletion, and was probably the right choice?
  3. In the future, using git commit -am "my message" could help, because commit -a captures deletions, where add . doesn't.
  4. Saw this one at commandlinefu git rm $(git ls-files --deleted) I didn't try it, but looks clever.

Anyhow, I still don't really know what the name of this is, so I'm not considering this an answer. Unindexed-deletions? Detatched deletion? Unstaged deletions?

Mittenchops
  • 18,633
  • 33
  • 128
  • 246
  • I think it's "Modified working tree". There is no significant difference between this state and if you just edited some files. – alex vasi Mar 06 '13 at 15:39
  • Always do a `git status`before committing and pushing. If you would have done that, you could have caught the problem at an earlier stage. `git rm --cache path/to/file` will remove the deleted file from git cache. – noMAD Mar 06 '13 at 15:43
  • Would it be correct to say something like, "You have staged (git add .) and committed (git commit) your additions, but have not staged (git add -u) and therefore, not committed your deletions?" Alex, I'd accept your comment as an answer unless someone else comes through knowing a magical name for my mistake here. =) – Mittenchops Mar 06 '13 at 21:53
  • @alexvasi, if you post your comment as an answer, I'll accept it. Else I'll accept this answer, pointing out your comment? – Mittenchops Mar 12 '13 at 02:53