'git commit' ignoring args?

With the latest git as of this writing, executing

	git commit Makefile stylesheet.xsl

results in an attempt to commit the above files, and also another file 
book.xml.  book.xml is modified, but I do not wish to check it in at 
this time, so I did not list it as an argument to 'git commit'.

The only commit in the repository is the initial commit.

#
# Updated but not checked in:
#   (will commit)
#
#       modified: Makefile
#       modified: book.xml
#       new file: stylesheet.xsl
#
#
# Untracked files:
#   (use "git add" to add to commit)
#
#       book.pdf

Expected behavior is that Makefile and stylesheet.xsl would be checked 
in, but not book.xml.

	Jeff

Jeff Garzik [off-list ref] writes:

With the latest git as of this writing, executing

	git commit Makefile stylesheet.xsl

results in an attempt to commit the above files, and also another file 
book.xml.  book.xml is modified, but I do not wish to check it in at 
this time, so I did not list it as an argument to 'git commit'.

The only commit in the repository is the initial commit.

#
# Updated but not checked in:
#   (will commit)
#
#       modified: Makefile
#       modified: book.xml
#       new file: stylesheet.xsl
#
#
# Untracked files:
#   (use "git add" to add to commit)
#
#       book.pdf

Expected behavior is that Makefile and stylesheet.xsl would be checked 
in, but not book.xml.

It should work that way, you are right.  And it worried me so
much that I tried to reproduce, but I couldn't.

The status output says it will _commit_ book.xml by listing it
in "Updated but not checked in" section, without listing it also
in "Changed but not updated".  Which means that when the
git-status was run (that is immediately after 'git-commit'
processed your command line and did git-update-index on Makefile
stylesheet.xsl for you), the index file had book.xml in sync
with your modified version in your working tree.

Could it be that at some point after touching book.xml before
running git commit you did update-index on it?


-- >8 --
Here is what I did to reproduce.

Start afresh.

        $ cd /var/tmp/
        $ rm -fr jg
        $ mkdir jg
        $ cd jg
        $ git-init-db
        defaulting to local storage area

Prepare two files and make initial commit.

        $ date >Makefile
        $ date >book.xml
        $ git add Makefile book.xml
        $ git commit -m 'Initial'
        Committing initial tree 4a7017a5ec4870d44c340943c66a7f0c1cf4885d

There are two files.

        $ git ls-tree HEAD
        100644 blob c803676f9cab3249b5b1d225e53b6d14c8545a5e	Makefile
        100644 blob 6f3b56bbff37d24d9faa78c3e0566cdab4dce8e9	book.xml

Modify two, add one.

        $ date >>book.xml
        $ date >>Makefile
        $ date >stylesheet.xsl
        $ git add stylesheet.xsl

See what happened.  The index file knows only about addition; we
have not told git about changes we did to book.xml and Makefile
yet.

        $ git diff --name-status --cached HEAD
        A	stylesheet.xsl

The working tree has three changes since the last commit.

        $ git diff --name-status HEAD
        M	Makefile
        M	book.xml
        A	stylesheet.xsl

The working tree is different from the index file in two paths.

        $ git diff --name-status
        M	Makefile
        M	book.xml

Do a partial commit, naming two files.

        $ git commit -m 'commit two' Makefile stylesheet.xsl

What's different between the working tree and what we just
committed?

        $ git diff --name-status HEAD
        M	book.xml

We should not have committed changes to book.xml; we haven't.

        $ git diff-tree --name-status HEAD
        1d3ed9f438aa705fd8433bc23400814468a1a353
        M	Makefile
        A	stylesheet.xsl
        $ exit

Jeff Garzik wrote:

With the latest git as of this writing, executing

    git commit Makefile stylesheet.xsl

results in an attempt to commit the above files, and also another file 
book.xml.  book.xml is modified, but I do not wish to check it in at 
this time, so I did not list it as an argument to 'git commit'.

The index has been updated to match the file on disk somehow (perhaps 
you did 'git add book.xml'?). You can un-mark it with

	git reset HEAD

which is equivalent to

	git read-tree --reset HEAD

so long as you're operating on HEAD.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Andreas Ericsson <ae <at> op5.se> writes:

The index has been updated to match the file on disk somehow (perhaps 
you did 'git add book.xml'?).

book.xml is known to the index file at this point.  "git add book.xml" will
*not* run update-index on that path, so that is not it.

Junio C Hamano wrote:

Andreas Ericsson <ae <at> op5.se> writes:

quoted

The index has been updated to match the file on disk somehow (perhaps 
you did 'git add book.xml'?).

book.xml is known to the index file at this point.  "git add book.xml" will
*not* run update-index on that path, so that is not it.

At this point, yes, but if it was just added it wouldn't have been 
before it was git-add'ed.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Junio C Hamano wrote:

Could it be that at some point after touching book.xml before
running git commit you did update-index on it?

Not according to scrollback, no.

-- >8 --
Here is what I did to reproduce.

Unfortunately, I cannot reproduce the problem either :(

Oh well, as long as the facility works in general, I'll live to fight 
another day :)

	Jeff