From: Shak <sshaikh@hotmail.com>
Date: Thu, 12 Jun 2008 12:23:53 GMT
Subject: Re: Deleting files
Message-ID: <g2r4ha$74i$1@ger.gmane.org>
In-Reply-To: <477B22F6-9F24-4CBE-98EE-58EF697E6320@ai.rug.nl>

"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