You are talking about two different operations.
Adding _new_ files, unless you are just beginning a new project,
are much more rare than updating modified files that you are
already tracking; and "git add new-file..." is what people
usually use for the former. "git add ." is almost always the
"initial import" and not used later (after all you ought to know
what files you are creating and controlling ;-)). You get into
an illusion that that is often used, only when you have just
started. As your project progresses, that feeling will fade
away.
And that is natural, if you think about it for 5 seconds.
"Add everything in sight, although I do not know what they are",
which is essentially what "git add ." is, makes perfect sense
for the initial import and vendor drop (after perhaps rm -fr
?*). If you are doing your own development, with your working
tree littered with build products and temporary notes files and
whatnot, "git add ." is usually the last thing you would want to
do.
Updating modified files, "git add -u", is more like "git commit
-a" (without creating commit). You do not add _new_ files, and
that is quite deliberate.
You _could_ argue that people should be more disciplined and
write perfect .gitignore files so that "git add ." is always
safe, but the world does not work that way.
On Aug 5, 2007, at 6:39 AM, Junio C Hamano wrote:
Adding _new_ files, unless you are just beginning a new project,
are much more rare than updating modified files that you are
already tracking; and "git add new-file..." is what people
usually use for the former. "git add ." is almost always the
"initial import" and not used later (after all you ought to know
what files you are creating and controlling ;-)). You get into
an illusion that that is often used, only when you have just
started. As your project progresses, that feeling will fade
away.
I exactly need the functionality that Miles is describing for
the following good reason:
Mac OS X has the notion of a bundle, which is a directory that
contains related files that are fully controlled by the application
that is writing that bundle. The bundle functionality is
directly supported by the OS and most applications save their
data as bundles. For example on Mac OS X, the Openoffice format,
which packs related files in a zip file, would just be a directory
with all related files grouped together (no ZIP archive needed).
So here is what I need: I want to be able to track a directory
with all its contents. The data inside the directory are not
under my control. It's only the directory that matters for me.
Git is already quite good at that because it doesn't need to
place anything inside the opaque directory! Subversion for example
has no chance because it clutters the directory with .svn
directories, which will be removed by the next Save (an
application first creates a new temporary directory, stores
all data there, moves the old directory to a backup location,
and renames the new directory to the final destination only
if no problems occurred).
When I started with git I figured out that
git-ls-files -z --others dir | git-update-index --add -z --stdin
git commit -a
does the job for me. Would
git add dir
git add -u dir
git commit
be equivalent, but restricted to the changes in dir?
Steffen