Hi, This may or may not be the same/similar as this thread [1] I noticed a while back that with gitk I kept on getting files shown as "Local uncommitted changes, not checked in to index" when I'd made modifications to them then backed them out so the working tree content was the same as the index. I used to (with git 1.6.x) fix / work around this by running git status. Now, with git 1.7.1, that workaround has stopped working. No doubt because git status was re-implemented from a wrapper of git commit to its own real command. Its then no surprise that running git commit "fixes" the problem even if its got nothing to commit. I think there is even another command to update whatever info gitk is reading but I can't find it right now. If I can ever remember the aforementioned magic command it shouldn't be hard to get gitk to run it when the user selects "reload" but I was wondering if this change in git status's behaviour is causing other issues (like in the thread I mentioned). Its fairly easy to reproduce this $ mkdir tmp $ cd tmp $ git init $ echo "foo" > foo.txt && git add foo.txt && git commit -m "Initial commit" $ touch foo.txt $ git status # On branch master nothing to commit (working directory clean) $ gitk # this is where you'll see foo.txt modified but not indexed $ git commit # On branch master nothing to commit (working directory clean) $ gitk # now everything is clean --- [1] http://article.gmane.org/gmane.comp.version-control.git/146473 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html