Home » Eclipse Projects » EGit / JGit » After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD
| After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823170] |
Fri, 20 March 2020 17:49  |
Eclipse User |
|
|
|
|
I upgraded to 2020-03 a couple of days ago. Since then, I've seen a couple of cases of files that show up in the "Unstaged changes" list in the "Git Staging View", and when I look at the changes in the file, there are none. I then right-click on it and select "Replace with HEAD revision". This results in ... no change. The file still has no changes, and still says there are unstaged changes, even after replacing it with the HEAD revision. This is happening in two different repos in our projects.
|
|
| | |
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823208 is a reply to message #1823189] |
Sun, 22 March 2020 17:47  |
| Eclipse User |
|
|
|
|
I just dumped the file with "od -h" and looked at every single line ending in the file. Every single one was a "\r" followed by a "\n", the same as in every other text file I've looked at. I also looked at the file in the BitBucket Server gui, but I don't know what I would look for. I suppose it's possible that if it's stored with inconsistent line endings on the server, when I checked it out it might try to normalize all the lines, making some different from the server and some not, which might make the client think there are differences, but the file display in the BitBucket Server gui doesn't offer the option of showing raw character codes.
|
|
| | | |
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823296 is a reply to message #1823295] |
Tue, 24 March 2020 13:50 |
| Eclipse User |
|
|
|
|
And now I see that this symptom is causing a bigger problem. No matter what I do, it thinks there are changes in that file, so it won't let me switch to another branch. It continually prompts me to discard, stash, or commit the changes. I can't commit the change, and I've tried discard and stash, and also a hard reset. I needed to make a change in that repo on another branch, and I had to ask someone else on the team to make the change.
|
|
|
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823302 is a reply to message #1823296] |
Tue, 24 March 2020 15:40 |
| Eclipse User |
|
|
|
1. Does this occur in a fresh clone, too?
2. Does this occur in a fresh clone cloned with core.autocrlf = false in your user git config?
3. Did you check whether the file was committed with mixed line endings?
4. Is this repo publicly accessible so that I could give it a try?
5. If not: can you put together a small public repo that reproduces the problem?
Regarding (3), I think you could get the raw file contents as committed using something like
git cat-file $(git ls-tree HEAD^1 PATH | cut -d' ' -f 2,3 | cut -f 1) > foo.txt
where PATH is the repository-relative path (using forward slashes /) of the file you want to check. The command places the result in file foo.txt; then examine that.
Oh, and one other thing: what's your setting for core.filemode? It should be set to false. Compare this old thread: https://www.eclipse.org/forums/index.php/m/1761332/#msg_1761332 .
|
|
|
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823306 is a reply to message #1823302] |
Tue, 24 March 2020 16:45 |
| Eclipse User |
|
|
|
1. Does this occur in a fresh clone, too?
Yes. In fact, this now shows TWO files with the same symptom.
2. Does this occur in a fresh clone cloned with core.autocrlf = false in your user git config?
NO. This seems like it would be a very important point, but I don't know what to make of this.
3. Did you check whether the file was committed with mixed line endings?
I don't see any way to determine that. Your command line to extract the "raw file" didn't give me any clues. The file in the original cloned repository appears to show all line endings as "\r\n" (shown in "od -c").
4. Is this repo publicly accessible so that I could give it a try?
No.
5. If not: can you put together a small public repo that reproduces the problem?
I don't see how. I don't understand why this is happening.
|
|
| | | |
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823326 is a reply to message #1823319] |
Tue, 24 March 2020 23:22 |
| Eclipse User |
|
|
|
I though so: the executable bit is set. It's a bug in JGit :-(. I'll fix this tomorrow. The problem should occur since EGit 5.6.0. What was your previous EGit version?
Out of interest: I assume this is a *.bat file. (A shell script with CRLF endings wouldn't work.) Why do you set the executable bit on that? I thought Windows didn't care?
As a work-around, try removing the executable bit (possibly via command-line git). That should resolve it.
|
|
|
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823329 is a reply to message #1823326] |
Wed, 25 March 2020 00:23 |
| Eclipse User |
|
|
|
Considering this isn't supposed to be an executable file, removing the bit should be no problem. We do have some shell scripts in git, but I don't typically check out that repository. Is this going to be a problem for those files?
I don't know what the previous version would have been. It would have been the one that went with 2019-12.
So you're suggesting I do a "chmod -x" on the file and commit that? Assuming that's what you mean, I guess I'll have to do this on my Linux VM. Because of this problem, I can't change to a feature branch to make the change, and I can't commit directly to master. It doesn't cause a problem on my Linux VM, so I should be able to do it there.
[Updated on: Wed, 25 March 2020 00:27] by Moderator Report message to a moderator |
|
|
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823330 is a reply to message #1823329] |
Wed, 25 March 2020 00:31 |
| Eclipse User |
|
|
|
|
Hmm, now that I'm looking at this a little closer, I find it hard to believe this could be the problem. I looked at that particular file, and looked at all the files in the same directory as that file. There are perhaps ten other files there, and ALL of them have the execute bits on. None of them are actually executable files, they are all configuration/property files. I'm seeing the symptom with one or two of these files.
|
|
| | |
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823374 is a reply to message #1823333] |
Wed, 25 March 2020 16:06 |
| Eclipse User |
|
|
|
Thomas Wolf wrote on Wed, 25 March 2020 01:12Then double check the other files. Do they have CR-LF or LF in the committed version? The problem occurs only for executable files where the committed version in the git repository has CR-LF line endings. (Which, if everybody working on Windows has core.autocrlf = true set, should not occur.)
I just went to my Linux VM, and used that "cat-file" example you cited above. The result showed \r\n sequences. This appears to be the abnormal situation you said should not occur. I believe in this case, "should" means "probably should not happen when people are paying attention".
So, it seems like this situation is a combination of a few problems. Our configuration files, which have been mangled in the repository with execute bits they don't need, and the wrong line endings, and your code somehow has trouble dealing with that mess. :)
|
|
|
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823378 is a reply to message #1823374] |
Wed, 25 March 2020 16:47 |
| Eclipse User |
|
|
|
Yes. The combination that triggers the bug is
- core.autocrlf=true (or equivalent settings via .gitattributes)
- executable bit on the git index version is set
- git index version uses CR-LF as line endings
The bug is only triggered if all three conditions are fulfilled.
Which also tells us possible work-arounds:
- set core.autocrlf=false (may not be practical)
- remove executable bit
- change git index version to use LF as line endings
Regarding (2): yes, that's chmod -x. To do so in the git index directly, I think it'd be "git update-index --chmod=-x path/to/file" or maybe (on newer git) "git add --chmod=-x path/to/file", then commit.
Regarding (3): one way of doing that is
- set core.autocrlf=false
- change line endings to LF in working tree file
- commit
- set core autocrlf=true
- checkout the file again, or reset
The file should now have LF in the git repository but CR-LF in the working tree again.
|
|
| |
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823957 is a reply to message #1823925] |
Sat, 04 April 2020 15:02 |
| Eclipse User |
|
|
|
|
Before installing the nightly update, I looked at two repos that were showing one modified file with no obvious changes. After the update, one of them resulted in no changes. After the update, I looked closer at the one that still had one file that stays in the "Unstaged changes" list even though it appears to have no changes. I used the "raw file" example you showed earlier on that file, and also on another file in the same directory that is not showing up in "Unstaged changes". The file that is NOT showing up in unstaged changes shows newlines with just "\n". The file that is still in "Unstaged changes" is showing newlines with "\r\n". Both files have permissions bits of "100644".
|
|
|
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823958 is a reply to message #1823957] |
Sat, 04 April 2020 15:51 |
| Eclipse User |
|
|
|
And what are the crlf settings in git config and gitattributes? What are the line endings in the file system?
Does the problem persist in a fresh clone?
Does the problem persist if you re-build the index? (Delete it and run a git status on the command line afterwards.)
It would be really helpful if you could put together a small demo repo at Github with which one could reproduce your problems. Without this, we're poking around in the dark.
|
|
|
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823961 is a reply to message #1823958] |
Sat, 04 April 2020 17:03 |
| Eclipse User |
|
|
|
Thomas Wolf wrote on Sat, 04 April 2020 08:51And what are the crlf settings in git config and gitattributes? What are the line endings in the file system?
Does the problem persist in a fresh clone?
Does the problem persist if you re-build the index? (Delete it and run a git status on the command line afterwards.)
It would be really helpful if you could put together a small demo repo at Github with which one could reproduce your problems. Without this, we're poking around in the dark.
I'll answer what I can answer for now, and ask some qualifying questions.
The "System" tab in git configuration shows core.autocrlf = true. This is Windows 10, so standard line endings are \r\n.
Curiously, a fresh clone of the same repository, with the same branch checked out, does not show the symptom.
I don't know how to check "gitattributes". I don't know how to delete the index.
If I run "git status" on the command line, I'll need to be reminded how to run the same git that Eclipse is using. My default command line git is from Cygwin, which I believe might present different results.
|
|
| |
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1823963 is a reply to message #1823962] |
Sat, 04 April 2020 18:22 |
| Eclipse User |
|
|
|
The process of deleting the index file and then doing a hard reset seemed to set it a good state, without the unexpected file in unstaged changes. When I first deleted the file from the shell, nothing happened until I tried doing a "fetch", and then it produced a surprising result, seeming to put every file in the repository in the unstaged changes list. That's when I did the hard reset, which cleaned everything up.
It's still curious that the changes in the nightly build fixed the problem immediately in one repository, but not the other.
So, I am now using the nightly build, which I did with "Install new software" and using the nightly update site. If I want to revert back to using the latest release for some reason, what do I have to do?
|
|
| |
| Re: After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD [message #1827498 is a reply to message #1823964] |
Fri, 15 May 2020 21:46 |
| Eclipse User |
|
|
|
|
Coming back to this, I am still using the nightly build. I noticed a little while ago that one repo was displaying this symptom, thinking a file with no actual changes was modified. I ignored it at the time because I didn't have to do much with that repo recently. Now I have to do something with it, and it's displaying the same symptom. discarding, stashing, or hard reset didn't fix it. I will proceed to delete the index file and see if that fixes it.
|
|
| |
Goto Forum:
Current Time: Fri Feb 14 19:32:29 GMT 2025
Powered by FUDForum. Page generated in 0.07962 seconds |
] 
Search
Help
Register
Login
Home
