'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 <jgarzik@pobox.com> writes:

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

Junio C Hamano wrote:

Not according to scrollback, no.

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

Jeff Garzik wrote:

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 <ae <at> op5.se> writes:

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:

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