On Sun, 5 Aug 2007, Miles Bader wrote:

quoted text
> I previously wrote
> > One thing I often want to do is git-add all untracked files, and also 
> > automatically git-rm all "disappeared" files
> ...
> > One way to do this seems to be just "git add ."
> 
> Oh, also, "git add ." doesn't seem to do the right thing with 
> "dissapeared" files:  If I do:
> 
>     mv foo.cc bar.cc
>     git add .

Do "git status -a" to figure out the removed ones.

I actually think we should probably make "git add ." do it too, but it's 
not how we've done it historically ("git add ." really ends up just 
reading the working directory tree and addign all the files it sees: so by 
definition it doesn't do anything at all to files it does *not* see, ie 
the removed ones).

quoted text
> Am I doing something wrong, or is this just missing functionality?

Well, it's just "behaviour". It's probably largely historical, in that 
"git add" used to be thought of as "adding new files", but obviously then 
it got extended to mean "stage old files for commit" too, but in that 
extension, the "remove old files" never came up.

But git certainly has the capability. "git commit -a" will notice all the 
files that went away and automatically remove them, so

	git add .
	git commit -a

will do what you want (except, as we found out last week, we've had a huge 
performance regression, so that's actually a really slow way to do it, and 
so it's actually faster to do

	git ls-files -o | git update-index --add --stdin
	git commit -a

instead (where the first one just adds the *new* files, and then obviously 
the "git commit -a" does the right thing for old files, whether deleted or 
modified)

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html