netbeans
netbeans copied to clipboard
File is shown as modified after undo to clean Git state
Apache NetBeans version
Apache NetBeans 15
What happened
When changing a file that is under Git control, and then changing it back to the original state in the editor by using Undo (saving the file each time), the Projects and Files view still continue to show the file as modified (filename in blue, versioning label "[-/M]"), although git status
reports a clean working tree.
How to reproduce
- Open a project under Git control with a clean working tree and index state (fresh checkout).
- Open a text file of the project within NetBeans.
- Make some trivial change to the text file in the editor, e.g. insert a space, and save the file. => The file is correctly shown as modified in the Projects and Files view.
- Use Edit > Undo in the editor to undo the change from step 3, then save the file, thus reverting it to the original clean state. => The file incorrectly continues to be shown as modified in the Projects and Files view.
Did this work correctly in an earlier version?
Apache NetBeans 12.3 or earlier
Operating System
Windows 10 Enterprise 22H1
JDK
Oracle JDK 8u271
Apache NetBeans packaging
Apache NetBeans provided installer
Anything else
As far as I can tell, this bug happens always.
Sometimes, a short while after switching from NetBeans to a different application window, or after NetBeans checks for external changes, the displayed status reverts to "not modified".
Messages.log shows no error.
This bug doesn't seem to happen in NetBeans 12.2, which is the version I previously used and still have installed.
Are you willing to submit a pull request?
No
Code of Conduct
Yes
adding the windows label since I never saw this before on linux.
You sure this isn't related to line ending settings?
What happens if you check the repo from outside of the IDE via git status
?
@mbien: I checked that the line endings are remaining the same (CRLF) in the file on disk. (Git core.autocrlf is set to true.) I also made a copy of the file before the modification and checked that they are binary equal after undoing the modification. So the Undo seems to be working correctly.
git status
says:
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
So I would expect NetBeans to also show no change.
I tested with another, much smaller project, and there it takes 1-2 seconds to update the versioning label. The project were the label only updates after a long time is a large Maven multi-module project with around 170 submodules and 11,000 Java source files. I only have one submodule opened in NetBeans, however code completion etc. seems to be seeing the source files of dependencies within that multi-module project.
So now I'm suspecting that NetBeans somehow, after saving the file, is doing something that depends on the size of the whole multi-module project, even though only one submodule is opened in NetBeans, and even though updating the versioning label of a file that is being changed from within NetBeans should be independent from the rest of the project. Also, as noted, I don't experience that behavior with NetBeans 12.2 (though the cache contents will be different in that version, which conceivably could make a difference).
good info. Might be indeed a performance problem under certain circumstances. I have a lot of netbeans modules open right now and it usually takes 1-3s until the status updates. But I have seen it slower before esp when a lot changes at once (e.g during a rebase via terminal).
It's a bit annoying, especially since git status
and git diff
take only ~100 ms to run on the whole multi-module project. Also, there are times when I wait several minutes and the status doesn't change. I don't know how to force it, other than restarting NetBeans, after which it seems to take half a minute or so to revert to the correct state.
In NetBeans, the state transition from "unmodified" to "modified" takes about six seconds in that project, after saving the file. It seems to me that there is no reason the reverse state transition from "modified" to "unmodified" should be significantly slower. Maybe that is an angle to attack the problem with, to see why the two state transitions behave differently in the implementation.
ok so this is not a bug but a windows specific performance issue.
org.netbeans.modules.git.FileStatusCache
in ide/git
is the entry point in case anyone is interested to investigate. Going to rename the issue.
This was a CRLF issue after all, where the Git index disagreed with the working tree. Closing.
I have this just for PHP projects. So the "workaround" is to change the CRLF for the files? Sometimes it shows "Refresh index" and runs forever. After restart NetBeans everything is fine. Maybe I will create a new ticket with detailed info.
@Chris2011: The concrete situation I had is that the local Git repo had originally been checked out with Cygwin, and therefore with unchanged line endings, while the Git implementation used by NetBeans was assuming Windows-native CRLF line endings. In addition, some text files in the Git repo had CRLF line endings, and were thus checked out as-is under Cygwin. When (hypothetically) committing those text files, their CRLF line endings would have been converted to LF in the index when using the Window implementation, and that version in the index would then be different from the original version in the repo. I think this is was caused NetBeans to display the files as modified. In any case, cleaning up the line endings in the remote repo and cloning it locally using the Windows Git implementation seems to have resolved the problem for me.