Re: Deleting files

From: Alex Riesen <raa.lkml@gmail.com>
Date: Jun 12, 2008, 20:44 UTC
Message-ID: <20080612204419.GA22787@steel.home>
In-Reply-To: <g2r4ha$74i$1@ger.gmane.org>

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

Show 16 quoted lines

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

Show 6 quoted lines

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

Show 5 quoted lines

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