On Sun, 24 Jun 2012 18:46:03 -0700 (PDT)
Git User <usv299792...@gmail.com> wrote:
> Thanks to everyone.
> Just one more thing:
> If we could exclude that `git add file' part from `git commit file',
> we would get the desired behavior, wouldn't we?
> It seems to me like `git commit --staget file' is a subset of the
> operation `git commit file'.
> Or I'm wrong ?
You seem to be wrong.
Seems like you did not grasp the concept of the Git staging area.
Git is different to many (all?) mainstream DVCSes in that it cuts its
commits not from your work tree but from a special "virtual" area
called "the index" or "the staging area" (earlier in Git's life it was
also called "the cache").
Initially the index is empty, you then do local modification to your
files and record *just those changes you want to be committed* by using
`git add <filename>`. When you subsequently call `git commit`, it's
the state currently maintained in index that gets committed, not the
changes in your work tree.
Alternatively it might turn out that you've been trained by some sloppy
person to always use `git commit -a` which means (`git add -u` + `git
So supposedly what you should use to achieve your original goal, is to
just `git add` the only file you need (to stage for committing only
those file's changes), do not add any other changed files and then
commit. The resulting commit will contain only the changes made
to that single file.
Note that `git add` supports one super-handy option, "--patch", which
even allows you to interactively pick single changes from the locally
modified file and stage for commiting only those you want leaving other
One good introductory read on this matter is the first part of .
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at