Ah, that explains it. I had already marked all my changes for update,
that's what threw me off here. Thanks!
Linus Torvalds wrote:
On Fri, 19 Aug 2005, Johnny Stenback wrote:
That made me assume that if I do:
git-commit-script somedir
it would *only* commit the changes I've made in "somedir", but it
appears to commit *all* files that have changed (and shows all files in
the list of changed files in the commit message it displays in the
editor), as if it's completely ignoring the <path> argument.
Known problem? I got this using git that I pulled from kernel.org
earlier this morning.
It works for me. You _should_ see something like
#
# Updated but not checked in:
# (will commit)
#
# modified: somedir/somefile
#
#
# Changed but not updated:
# (use git-update-cache to mark for commit)
#
# modified: otherdir/anotherfile
#
which basically means that it will commit "somedir/somefile", but _not_
commit "otherdir/anotherfile".
However, one thing to look out for is that if you've marked any files for
update (with git-update-cache) those will always be committed regardless
of what arguments you give to "git commit". You can reset the index with
"git reset" if you decided that you don't want to commit after all.
(For example, if you do a "git commit --all", but decide not to commit
after all by writing an empty commit message, that will already have
marked all the files to be committed, so next time, even if you then use
"git commit somedir", all the files in all the _other_ dirs have already
been marked for update, so you'll see everything being committed).
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
jst
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
