threads / bug / 23725

change in behaviour of git status and/or gitk bug

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

## tl;dr

3 messages between May 7, 2010 and May 7, 2010.

replies: 2people: 2as markdown or json

Chris Packham· May 7, 2010, 01:20 UTC · lore

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

Jeff King· May 7, 2010, 05:00 UTC · re: Chris Packham · lore

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

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

Show 7 quoted lines

> 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

Chris Packham· May 7, 2010, 16:47 UTC · re: Jeff King · lore

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

On Thu, May 6, 2010 at 10:00 PM, Jeff King <peff@peff.net> wrote:

Show 23 quoted lines

> 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.