change in behaviour of git status and/or gitk bug

[Chris Packham <judge.packham@gmail.com>]

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