Deleting files

Deleting files

[Shak]

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 

Re: Deleting files

[Shak]

"Shak" <sshaikh@hotmail.com> wrote in message 
news:g2r19e$s6e$1@ger.gmane.org...
> 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? :(

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 

Re: Deleting files

[Shak]

"Shak" <sshaikh@hotmail.com> wrote in message 
news:g2r1sb$tut$1@ger.gmane.org...
> "Shak" <sshaikh@hotmail.com> wrote in message 
> news:g2r19e$s6e$1@ger.gmane.org...
>> 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? :(
>
> 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?
>

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 

Re: Deleting files

[Pieter de Bie]

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

> This is all becoming very counter-intuitive :(

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

Re: Deleting files

[Shak]

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

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 

Re: Deleting files

[Alex Riesen]

Shak, Thu, Jun 12, 2008 14:23:53 +0200:
> "Pieter de Bie" <pdebie@ai.rug.nl> wrote in message  
> news:477B22F6-9F24-4CBE-98EE-58EF697E6320@ai.rug.nl...
>>
>> 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>".
>>
>
> 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.

"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).

> 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 .

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..."?

> git add -u
> git commit
>
> Is that right? Should the two add commands be called in that order or  
> doesn't it matter?

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

> 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?

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.