On Sun, 5 Aug 2007, Miles Bader wrote:
> 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).
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
