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

[Jakub Narebski <jnareb@gmail.com>]

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