change in behaviour of git status and/or gitk bug

change in behaviour of git status and/or gitk bug

[Chris Packham]

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

Re: change in behaviour of git status and/or gitk bug

[Jeff King]

On Thu, May 06, 2010 at 06:20:34PM -0700, Chris Packham wrote:

> 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

This was lost in v1.7.0, but should be back in v1.7.2. The actual fix is
4bb6644 (git status: refresh the index if possible, 2010-04-02).

You can run "git update-index --refresh" to get the same effect. Running
"git diff" also works.

There was some talk (and a patch) recently about gitk running
"update-index --refresh", but I don't know if it got picked up. See:

  http://article.gmane.org/gmane.comp.version-control.git/144182

-Peff

Re: change in behaviour of git status and/or gitk bug

[Chris Packham]

On Thu, May 6, 2010 at 10:00 PM, Jeff King <peff@peff.net> wrote:
> On Thu, May 06, 2010 at 06:20:34PM -0700, Chris Packham wrote:
>
>> 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
>
> This was lost in v1.7.0, but should be back in v1.7.2. The actual fix is
> 4bb6644 (git status: refresh the index if possible, 2010-04-02).
>
> You can run "git update-index --refresh" to get the same effect. Running
> "git diff" also works.
>
> There was some talk (and a patch) recently about gitk running
> "update-index --refresh", but I don't know if it got picked up. See:
>
>  http://article.gmane.org/gmane.comp.version-control.git/144182
>
> -Peff
>

OK good to know its not just me.

I'd add my vote for gitk running "update-index --refresh" in response
to a user asking it to refresh, which should satisfy the "gitk doesn't
touch anything unless you ask it to" requirement.