Home » Eclipse Projects » EGit / JGit » After upgrade to 2020-03, egit sees unstaged changes even after replace with HEAD
| | | | | | | | | | | | | |
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 |
David M. Karr Messages: 813 Registered: July 2009 |
Senior Member |
|
|
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] Report message to a moderator
|
|
| | | |
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 |
David M. Karr Messages: 813 Registered: July 2009 |
Senior Member |
|
|
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 #1823961 is a reply to message #1823958] |
Sat, 04 April 2020 17:03 |
David M. Karr Messages: 813 Registered: July 2009 |
Senior Member |
|
|
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 |
David M. Karr Messages: 813 Registered: July 2009 |
Senior Member |
|
|
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?
|
|
| | | |
Goto Forum:
Current Time: Mon Dec 09 01:25:02 GMT 2024
Powered by FUDForum. Page generated in 0.06651 seconds
|