"Pieter de Bie" <pdebie@xxxxxxxxx> wrote in message
news:477B22F6-9F24-4CBE-98EE-58EF697E6320@xxxxxxxxxxxx
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
