Deleting files

Hi,

Are files supposed to be continually tracked after commiting after deleting them?

git status reports that files have been deleted as expected (they're not there anymore). I commit as wanted. I do some more work, but then git status still reports that the same files have been deleted. As such I have a historical list of "deleted" files that I may have been working on previously and had committed.

I have to run git rm to erase these entries, but I've no idea how that affects my history.

Shouldn't git add/commit remember that a file has been deleted previously?

On a related note, once I do git rm on one of these files, git status sometimes reports that these rm'd files have been renamed to a new one instead! What's going on? :(

Shak 

"Shak" <sshaikh@hotmail.com> wrote in message news:g2r19e$s6e$1@ger.gmane.org...

To be clear on the last point, git seems to be incorrectly detecting that I've copied (sometimes to the same directory) and renamed files. What's the difference anyway? And is there anyway to override it's overzelaous assumptions?

Shak 

"Shak" <sshaikh@hotmail.com> wrote in message news:g2r1sb$tut$1@ger.gmane.org...

To rudely reply to my own message a second time, it seems I have to explicitly run "git add -u" to actually commit deletions before committing. I don't notice any changes in "git status" so there doesn't seem a way of knowing that it's required.

I've also noticed that renames aren't detected until you commit a delete.

This is all becoming very counter-intuitive :(

Shak 

On 12 jun 2008, at 14:01, Shak wrote:

It seems you are missing the concept of the index. Let's look
at an example:
Vienna:a pieter$ git init
Initialized empty Git repository in /Users/pieter/a/.git/
Vienna:a pieter$ touch a b
Vienna:a pieter$ git commit -m "Initial commit"
Created initial commit f0a0fe2: Initial commit
  0 files changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 a
  create mode 100644 b
Vienna:a pieter$ rm a
Vienna:a pieter$ git status
# On branch master
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#
#       deleted:    a
#

This is the point where you were. Look at the line "Changed but no updated" and also the hint "(use "git add/rm <file>..." to update what will be committed)".

Vienna:a pieter$ echo "text" >b && git add b && git commit -m "change"
Created commit e28a131: change
  1 files changed, 1 insertions(+), 0 deletions(-)

You changed b and commited it, but did nothing with a. now when you do git status:

Vienna:a pieter$ git status # On branch master # Changed but not updated: # (use "git add/rm <file>..." to update what will be committed) # # deleted: a # no changes added to commit (use "git add" and/or "git commit -a")

It'll still show it as deleted. And still gives you a hint on what to do (TWICE!). So, let's do that:

Vienna:a pieter$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # deleted: a #

Notice that it now says "Changes to be committed"! If you commit now, your status will be clean:

Vienna:a pieter$ git commit -m "deleted a"
Created commit 02bbe7b: deleted a
  0 files changed, 0 insertions(+), 0 deletions(-)
  delete mode 100644 a
Vienna:a pieter$ git status
# On branch master
nothing to commit (working directory clean)

In short, the point is that you never commited the deletions! Your whole history until now will still show those deleted files. You can commit the actually deletions now, as you should have done before (either by using "git rm <file>", "git add -u", "git commit -a" or "git commit <file>".

- Pieter

"Pieter de Bie" <pdebie@ai.rug.nl> wrote in message news:477B22F6-9F24-4CBE-98EE-58EF697E6320@ai.rug.nl...

Thanks for the quick workflow. To fill in a gap in my OP, I was using "git add ." to add new files before a "commit". Since I (perhaps incorrectly) took "commit -a" as a short cut for these two commands, I assumed that "git add ." would also commit deletions.

So sticking to my previous workflow (I need to do this since "commit -a" as I understand it doesn't commit new files, and I often forget that I've added :)), it seems I should do the following to keep the working directory in sync with the repository:

git add . git add -u git commit

Is that right? Should the two add commands be called in that order or doesn't it matter?

I ask because I'm still concerned with how git assumed I had renamed files after I had "git rm"d them. As far as I could tell they were not very alike. Perhaps adding the new files before removing the old ones would stop this behavior?

Shak 

Shak, Thu, Jun 12, 2008 14:23:53 +0200:

"git add" just adds, unless told to update (with -u). And "git commit -a" just updates and commits. Updates include forgetting removed files, but not adding new (thats on purpose: too many of us have random files in our working trees).

this will add everthing which isn't ignored (in .git/info/exclude or .gitignore's). Are you sure you want that generated and backup files in your history? Maybe your workflow could use "git add new-file-1 new-file-2..."?

either "git add . && git commit -a" or "git add . && git add -u && git commit".

Why should you care? They seem to be similar enough, but besides the listing, there is nothing which relates them in the git structures. Happens often for small files.

Just adopt "git commit -a" and ignore that.