netbeans icon indicating copy to clipboard operation
netbeans copied to clipboard

File is shown as modified after undo to clean Git state

Open nmatt opened this issue 2 years ago • 5 comments

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

  1. Open a project under Git control with a clean working tree and index state (fresh checkout).
  2. Open a text file of the project within NetBeans.
  3. 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.
  4. 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

nmatt avatar Oct 12 '22 01:10 nmatt

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 avatar Oct 12 '22 11:10 mbien

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

nmatt avatar Oct 12 '22 17:10 nmatt

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

nmatt avatar Oct 12 '22 17:10 nmatt

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

mbien avatar Oct 12 '22 17:10 mbien

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.

nmatt avatar Oct 12 '22 19:10 nmatt

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.

mbien avatar Oct 13 '22 16:10 mbien

This was a CRLF issue after all, where the Git index disagreed with the working tree. Closing.

nmatt avatar Apr 18 '23 13:04 nmatt

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 avatar Apr 18 '23 13:04 Chris2011

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

nmatt avatar Apr 19 '23 11:04 nmatt