gitk lists my already committed files as "Uncommitted changes", but shows empty diffs

[asm warrior]

I'm using msysgit Git-1.9.5-preview20141217.exe under WinXP.

After I commit all the changes by the "git gui" tool fired from the "gitk" menu->Start git gui. When I close the git gui, and returned to gitk, I try to press the F5 to reflesh the git history, but I still see "Uncommitted changes" shows in top of the git history, the listed changed files are in fact the files I just commited totally. When I click on the file name in the right bottom sub window of gitk, it shows empty diffs in the left bottom sub window of the gitk.

Press the F5 to reflesh the git history seems doesn't solve this issue.

If I run the "git status" in the bash command line, and thoes files are not shown, which means my working copy is unmodified.
Close the gitk, and reopen it I see "Uncommitted changes" is gone.

Any ideas about this issue? Thanks.

BTW: I have core.autocrlf = true in the config settings.

[Philip Oakley]

From: asm warrior

To: msy...@googlegroups.com

Sent: Saturday, February 14, 2015 3:10 PM

Subject: [msysGit] gitk lists my already committed files as "Uncommitted changes", but shows empty diffs

Which gitk command did you use (i.e what arguments) or was it started by some other programme. It may be that what was commanded can't be refreshed in the way you'd expect.

 

I've found the refresh (F5) and reload (shift-F5) appear to work OK for me (though I'm not realy sure of the difference;-)

 

Philip

 

[asm warrior]

On Sunday, February 15, 2015 at 5:22:01 AM UTC+8, Philip Oakley wrote:



Hi, Philip, thanks for the reply.
This is the screen shot that I got. See attachment. I have shown the empty diffs in the left bottom window.

Here is the steps to reproduce:

1, create an empty folder "D:\temp\test-gitk-refresh"
2, context menu on the folder, and click "Git Init Here"
3, create one file in the folder, named "a.c", enter some text and save
4, context menu on the folder, and click "Git Add all files now"
5, context menu on the folder, click "Git Commit Tool", and commit, close the Git Gui window
6, enter more text in a.c and save
7, context menu on the folder, click "Git History", then gitk is open, I see "Local uncommitted changes..." on top of history
8, click on "a.c" in the right bottom window(there is a file list), then it shows the diffs in left bottom window.
9, click on the menu of gitk, File->"Start git gui"
10, in the new opened git gui, stage the changes, and commit, and close the git gui window, return to the gitk.
11, press F5 to refresh the git history, the "Local uncommitted changes..." issue happens.

Oh, I just found the reason which may cause the issue. When I run "git config --list", I see two occurrences of "core.autocrlf = "

core.autocrlf=true
...
core.autocrlf=True

I just suspect that "True" is not a correct keyword here, so later wrong statement overwrites the first correct one.
Checking the file: C:\Documents and Settings\myusername\.gitconfig, I did see the suspected statement

[core]
    autocrlf = True

So, I just remove the line "autocrlf = True", and do the tests again, the issue still exists. The strange thing is that the "git bash" is already shown a clean working copy. I guess the gitk use some cached config files? So I try to close all the applications and windows on my windows desktop, and try to run gitk again, this time, I don't see the "Local uncommitted changes..." issue, I did some more tests and I don't see this issue happens again.


Sorry about the noise. I have never enter the line "autocrlf = True" myself, maybe some programs like tortoisegit or git extension cause this issue. but currently I don't use those programs any more(I just uninstall them several days ago), I think the gui (gitk and git gui)supplied by Git-1.9.5-preview20141217.exe is good enough.




 

 

 

[Michael Geddes]

There are definitely some fishy things going on, and there's actually a bug that I logged and started working on.

 

I uncovered a bunch of issues with inconsistencies in CRLF conversion that cause this problem. I do have a branch pushed up to my fork but I think it's missing a couple of commits that I have done since.

 

If you can reproduce it in a clean repo as a test that would be excellent.

 

 

//.ichael

--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
 
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msy...@googlegroups.com
To unsubscribe from this group, send email to
msysgit+u...@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

---
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[asm warrior]

On Sunday, February 15, 2015 at 8:43:15 AM UTC+8, Michael wrote:

There are definitely some fishy things going on, and there's actually a bug that I logged and started working on.

 

I uncovered a bunch of issues with inconsistencies in CRLF conversion that cause this problem. I do have a branch pushed up to my fork but I think it's missing a couple of commits that I have done since.

 

If you can reproduce it in a clean repo as a test that would be excellent.

 

 

//.ichael

 

Hi, Michael, thanks for the reply. I don't have ability to build the git.exe from your branch. (btw, I also don't know where your branch locates).
If there are many chances that you can supply a pre-build binary version, I'd grad to test it. In fact, my previous test result is from a clean repo in my local computer.

Thanks.

[Torsten Bögershausen]

On 2015-02-15 01.43, Michael Geddes wrote:
[]

>
> I uncovered a bunch of issues with inconsistencies in CRLF conversion that cause this problem.
> I do have a branch pushed up to my fork but I think it's missing a couple of commits that I have done since.
>

Thanks for de-bugging:
For those who are interested, like me:
Is the a public repo, and do you want to share the URL with us?

[Michael Geddes]

Sorry it's taken a while to get back to you all.

 

Here's the url of branch on github. It still needs some test cases to be properly accepted into the tree. I think this should all be going upstream.. just gotta get it right.

 

https://github.com/frogonwheels/git/tree/mrg/blame-crlf-v2

 

One of the reasons I held off was that I was seeing issues in gvim 'fugitive' plugin.. and found out the reason was because the input was being piped from stdin and _that_ wasn't being checked for CRLF standardisation. Fixed and pushed.

 

//.ichael

[Michael Geddes]

This is the bug report I filed:

https://github.com/msysgit/git/issues/260

 

//.

--

[Michael Geddes]

 

I'd be interested in the output to the following:

 

either from bash

git config -l | grep 'crlf\|eol'

or cmd

git config -l | grep 'crlf\^|eol'

or cmd (if you don't have grep in the path)

git config -l | findstr crlf && echo.-- && git config -l | findstr eol

 

 

One of the issues I found was where I had 'core.autocrlf=false' and 'core.eol=crlf'. This definitely highlighted the problem.

 

This came about because I had

core.autocrlf=true

in the default system config, but wanted to use 'core.eol' in a specific config.

 

The other thing to check is to make sure you haven't committed a file with CRLF into the repository.

 

You can use git ls-files -s -- <filename> to find the SHA1 of the file object.. then

git cat-file -p <sha1> | gvim - -c "set fileformat?"

 

should show 'fileformat=unix' at the bottom of your gvim session. (fileformat=dos means you have a problem)

 

Michael

[asm warrior]

On Wednesday, February 18, 2015 at 8:39:14 AM UTC+8, Michael wrote:

 

I'd be interested in the output to the following:

 

either from bash

git config -l | grep 'crlf\|eol'

or cmd

git config -l | grep 'crlf\^|eol'

or cmd (if you don't have grep in the path)

git config -l | findstr crlf && echo.-- && git config -l | findstr eol

 

 

Hi, Michael, thanks. Today, the problem I reported in my original post happens again. So, I follow your advice, and here is the result:

$ git config -l | grep 'crlf\|eol'
core.autocrlf=true

It looks like this value is OK.

 

One of the issues I found was where I had 'core.autocrlf=false' and 'core.eol=crlf'. This definitely highlighted the problem.

 

This came about because I had

core.autocrlf=true

in the default system config, but wanted to use 'core.eol' in a specific config.

Well, I think my reported issue is not related to this one.

 

The other thing to check is to make sure you haven't committed a file with CRLF into the repository.

 

You can use git ls-files -s -- <filename> to find the SHA1 of the file object.. then

git cat-file -p <sha1> | gvim - -c "set fileformat?"

 

should show 'fileformat=unix' at the bottom of your gvim session. (fileformat=dos means you have a problem)

 

Michael

When the issue happens, the stage area is empty, so git ls-files gives empty result.

BTW: I found another way to reproduce my issue: suppose the gitk show a clean working tree.
1, In gitk gui window, right click on the previous commit, and soft reset to previous commit.
2, now, I see some local changes, then I use the external diff tool to remove all the local changes.
3, refresh again the gitk, then the files which are identical to the files in index are still listed as "Uncommitted changes", but I see empty diffs in the left bottom window of gitk window.
 

 

[Philip Oakley]

----- Original Message -----

From: asm warrior

To: msy...@googlegroups.com

This last point suggests to me that part of the issue is the different ways different Git+file systems determine if the file has changed. The internal index maintains a timestamp of when it last saw the file changes. If the file has been 'touched' then Git thinks that there will be some associated changes - and in this case the only difference is the time stamp, which Git itself does not record in the repo (but it does in the index.

 

I've forgotten what OS you are on, and what shares you may be using (another issue for file time stamps), but it could be that, especially if your tools/process keeps touching those files without really changing them.

[asm warrior]

On Sunday, February 22, 2015 at 11:24:47 PM UTC+8, Philip Oakley wrote:



This last point suggests to me that part of the issue is the different ways different Git+file systems determine if the file has changed. The internal index maintains a timestamp of when it last saw the file changes. If the file has been 'touched' then Git thinks that there will be some associated changes - and in this case the only difference is the time stamp, which Git itself does not record in the repo (but it does in the index.

 

I've forgotten what OS you are on, and what shares you may be using (another issue for file time stamps), but it could be that, especially if your tools/process keeps touching those files without really changing them.

HI, Philip, thanks for the reply.
I'm using Windowns XP(with SP2 or SP3 I'm not quite sure).
I just searched the "msysgit time stamp", and I found on issue that may be related to my original post:
[msysGit] Issue 478 in msysgit: Files with changed time stamps but no content changes causes continuous rescan of git GUI - Google Groups - https://groups.google.com/forum/#!topic/msysgit/J-rciLZQe6s

For me, I don't see time stamp related settings in gitk. And in git gui's setting dialog, I do see the "Trust File Modification Timestamps" checkbox is NOT  
checked.

When I run git config -l from bash, I don't see time stamp related settings.

BTW: I found one FAQ: 3.11 Why does "git diff" sometimes list a file that has no changes? - https://git.wiki.kernel.org/index.php/Git_FAQ#Why_does_.22git_diff.22_sometimes_list_a_file_that_has_no_changes.3F
So, does gitk use "git diff" to fetch the changed files? Any way to let gitk to run "git status"? It looks like in my bash command line,  git status don't expose my reported issue.

Thanks.

[asm warrior]

I found a workaround to my original post.
When the issue happens, I need to run "git status" in the bash command line. After that, go back to the gitk gui, and refresh the history, and the "Uncommitted changes...." message is gone.

Is there any way to force gitk to run "git status"? Press the Menu->File->Update or Menu->File->Reload seems does not solve the issue.

[asm warrior]

Now, I think I found the reason of my reported issue by reading the source code of gitk. (I'm not familiar with TK/TCL language, so I can only guess)
It turns out that gitk use the "git diff-files" to fetch the changed files, see its source gitk around line 5240 in the function proc readdiffindex {fd serial inst}

...    
    # now see if there are any local changes not checked in to the index
    set cmd "|git diff-files"
    if {$vfilelimit($curview) ne {}} {
    set cmd [concat $cmd -- $vfilelimit($curview)]
    }
...

Now, I just did some test in bash, see the log below:

mypc@MYPC /D/temp/test-gitk-refresh (master)
$ git diff-files

mypc@MYPC /D/temp/test-gitk-refresh (master)
$ touch a.c

mypc@MYPC /D/temp/test-gitk-refresh (master)
$ git diff-files
:100644 100644 6846aa9e79874d5957d450678ac47f50513521e4 000000000000000000000000
0000000000000000 M      a.c

mypc@MYPC /D/temp/test-gitk-refresh (master)
$ git status
On branch master
nothing to commit, working directory clean

mypc@MYPC /D/temp/test-gitk-refresh (master)
$ git diff-files

mypc@MYPC /D/temp/test-gitk-refresh (master)

So, you can see that git diff-files will give empty result only after I run the "git status", which I believe refresh the index.

So, do we need to run some git command to refresh the index before the git diff-files? Or maybe, it is by design?

Thanks.

[Philip Oakley]

----- Original Message -----

From: asm warrior

To: msy...@googlegroups.com

Cc: asmwa...@gmail.com ; philip...@iee.org

Sent: Monday, February 23, 2015 5:33 AM

Subject: Re: [msysGit] gitk lists my already committed files as "Uncommitted changes", but shows empty diffs

Ultimately, this is "All by design", and "the one true way".

 

One has to remember that Git is the VCS of Linux/Linus, so at it's heart it presumes that the file representation and status is done the Unix/Linux/Posix way, so that it can use heuristics optimised to those assumptions. Obviously, Microsoft (XP, Win7, etc) chose subtly different, but importantly different, assumptions that better suited it's broad client base.

 

On windows, some of the parts of the linux heuristics are missing or can't be trusted in the same way, so 'almost but not quite' equivalents are substituted for the normal status checks, which makes files show up as 'possibly changed' where on linux they probably wouldn't be. In addition tools on windows make those windows style working assumptions an go tweak the file system status as well, again making Git think a file might have changed.

 

Git Gui then does proper diffs on those detected as different with diff-files (e.g. time stamp change), and shows 'no changes'. If you tried to 'add' such a file, then a full check would be done and the lack of a true diff would be noticed and you'd be warned/errored (IIRC).

 

Have a look at the thread on the main Git list "[PATCH 0/3] Win32: nanosecond-precision file times" http://thread.gmane.org/gmane.comp.version-control.msysgit/21290 (12 Feb 2015, so relatively new) for some of the more recent discussions - it may have been your original problem(? - something in VSS2Git?).

 

What I usually do on the Git Gui when in doubt is hit the refresh button, usually because I've done something else in another window (e.g. a VS2008 attempted build of the code)

 

Glad to hear that you've had a delve into the code. Been there, got the T-shirt dirty.

 

Philip