1

I'm building a historical record of development into git from saved zip files. I'm happy about the need to git add . files to the staging area so that the selected files are committed. So far so good.

However I'm now in the situation of simply adding the first (unzipped) file set, committing them, then deleting their directory and contents, before unzipping the next set, adding them and committing, often with variant directory names.

My problem of understanding is that I'm getting "unstaged changes" showing (Git Gui) of directorie/files I deleted a few commits back. I understood that git takes a snapshot of the current files, so shouldn't have any deleted files in there.

So, have my recent commits contained copies (in their tree) of those deleted files? When/why does git rm need to be used instead of a plain rm (or windows equivalent)? Should I just ignore the message? i.e. Are there explanations of how git handles the competing deletion & tracking mechanisms.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Philip Oakley
  • 13,333
  • 9
  • 48
  • 71

2 Answers2

4

If you simply delete by using rm and then commit, that removal is not staged, so git just ignores the fact that that file is gone.

If you want git to recognize the removal of that file and update the repository accordingly, you have to git rm a file. In your case, git add -A . after deleting the old and unzipping the new will give you what you want. It adds all adds, deletes, and changes to the staging area.

With your current plan, you certainly have many files in the repository that you do not want. Your best bet is to start over, using the following strategy.

  1. Create repo
  2. Unzip files
  3. git add -A .
  4. git commit
  5. Delete all files
  6. Repeat from 2
Kyle Heironimus
  • 7,741
  • 7
  • 39
  • 51
  • Kyle: I've used your loop but added `git commit -a -m "Message" --date "2009-12-25 13:00:00"` to the commit so I get sensible dates and the `-a` to double check that git notices and records all removals. – Philip Oakley Jul 28 '11 at 20:21
1

Your guess it right--the recent commits contained copies of those deleted files.

Try git add -A ., it stage deletion as well.

If you want to know why..... because that's what staging area are best used: git have a concept of "stage area", which allow you commit only part of your modification -- this make splitting patches easier.

J-16 SDiZ
  • 26,473
  • 4
  • 65
  • 84
  • It's the idea that the Staging area keeps a duplicate copy of your file until such time as you actively delete the staging area's copy that I hadn't appreciated. It's one of those 'implied but not stated' areas of git. It probably means i'll need to restart the history build, unfortunately. – Philip Oakley Jul 28 '11 at 14:37
  • 1
    You can use `git alias` to do an alias for whatever you prefer. – J-16 SDiZ Jul 28 '11 at 14:50
  • @J-16 SDiZ: a small typo: you've put the `-A` in the wrong place - it needs to go right after `add`. – Mark Longair Jul 28 '11 at 15:52
  • J-16: I've marked this as the right answer because it confirmed that the commit would have contained files that I thought I had deleted. – Philip Oakley Jul 28 '11 at 20:10