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

> 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.