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