Re: [FAQ?] Rationale for git's way to manage the index

Carl Worth wrote:

This reminds me of a confusing semantic issue that came about with the
"new" add. It can be quite natural to commit a single file in one step
with:

      git commit some-file.c

or to do that in two steps with:

      git add some-file.c
      git commit

(which is particularly useful if one wants to add multiple files).

I recently found myself wanting to do a similar thing with a directory
path. I can commit a path with:

      git commit path/

but I don't get anything at all like the same semantics if I do:

      git add path/
      git commit

(since "git add" will recursively add all untracked files under path/).

Now the "recursively add all files" behavior is older, and has been an
essential part of git-add forever. But I found it to be not at all
what I wanted in this case, (where I'm now trained to say "git add" to
stage things into the index).

I don't know of any good fix for the problem now. Maybe I'll just need to
remember to break out that old "git update-index" for a situation like
this, but that sure feels clunky.

In the new version of git I *think* you can use "git add -u path/"

  'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] <file>...

  -u::
        Update all files that git already knows about. This is what
        "git commit -a" does in preparation for making a commit.

(in v1.5.2-rc0, documented in v1.5.2-rc3).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git