Question

$ git --version
git version 1.7.0.3

I clone an SVN repository, and make a commit:

$ git svn clone --stdlayout http://svn/example/project
$ echo test >> blah.txt
$ git commit -m "Something"

When I try and dcommit back to the SVN, I get the following error:

$ git svn dcommit
Cannot dcommit with a dirty index.  Commit your changes first, or stash them with `git stash'.
 at .../git/1.7.0.3/.../libexec/git-core/git-svn line 497

..despite the branch being seemingly clean:

$ git status
# On branch master
nothing to commit (working directory clean)

The only place I can see the non-existent “unstaged changes” is in gitk, where it says “Local uncommitted changes, not checked in to index”

Running git stash allows the dcommit to work for some reason:

$ git stash
No local changes to save
$ git svn dcommit
Committing to http://svn/example/project ...
        M       blah.txt
Committed r65913
        M       blah.txt
r65913 = a5547d761108d233211f115429e23ddca73bf4bc (refs/remotes/trunk)
No changes between current HEAD and refs/remotes/trunk
Resetting to the latest refs/remotes/trunk

I have an alias to run git stash; git svn dcommit; git stash apply – but this is not the best workaround, as it causes merge errors when using actually using the stash

Answer 1

As I was writing the question, I found the following commit:

http://repo.or.cz/w/git.git/commitdiff/181264ad590ffef9d956fdd023369869c2d0a55f

The dcommit command fails if an
otherwise unmodified file has been
touched in the working directory:

Cannot dcommit with a dirty index.  Commit your changes
first, or stash them with `git stash'.

This happens because “git diff-index”
reports a difference between the index
and the filesystem:

:100644 100644 d00491...... 000000...... M      file

The fix is to run “git update-index
–refresh” before “git diff-index” as is done in git-rebase and
git-rebase–interactive before “git
diff-files”.

This changes dcommit to display a list
of modified files before exiting.

Also add a similar test case for “git
svn rebase”.

Can’t decipher from the git log what version the change is in, but it looks like the change should be in the version after 1.7.2.2

Edit: As of Nov 19, 2011, the commit is still only in the master branch:

$ git branch --contains 181264ad590ffef9d956fdd023369869c2d0a55f
* master

Edit2: This change is now in git 1.7.3 onwards

> git tag --contains 181264ad590ffef9d956fdd023369869c2d0a55f | sort -V
v1.7.3
[...]