-
Notifications
You must be signed in to change notification settings - Fork 5.7k
Staging area: fix issues with refreshing editor highlighting for new and untracked files. #3359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Staging area: fix issues with refreshing editor highlighting for new and untracked files. #3359
Conversation
For untracked files, GitStageLineStatusTrackerProvider#loadContent normally returns null. However, for added files empty TrackedContent instances are created. If such a file becomes unstaged, loadContent is not invoked again because the HEAD position is unchanged, leaving stale editor highlighting in place. This commit prevents base content from being created for untracked files, avoiding incorrect highlighting. IJPL-225212
…fter committing new file After a commit, GitStageLineStatusTrackerProvider#loadContent may be invoked while GitStageTracker statuses are not up-to-date yet. In particular, after committing a new file, its status can temporarily remain added, causing loadContent to return empty content. Once the status is refreshed, loadContent is not called again because the HEAD position has not changed, leaving base content outdated. This commit includes the file status in ContentInfo so that status changes can trigger a loadContent call. IJPL-181327
…aded for unchanged files When an added file becomes untracked again, it may be briefly reported as unchanged because GitUntrackedFilesHolder and GitStagingAreaHolder are refreshed independently. During this period GitStageLineStatusTrackerProvider can try to load base content and report a warning. This commit logs the condition at debug level instead to avoid polluting log files.
|
JFYI: if these commits are applied, mind the commit message: git can trim the "[git-index]" prefix from the message when applying a patch. |
| catch (e: VcsException) { | ||
| LOG.warn("Can't load base revision content for ${file.path} with status $status", e) | ||
| val message = "Can't load base revision content for ${file.path} with status $status" | ||
| if (status.isNotChanged()) LOG.debug(message, e) else LOG.warnWithDebug(message, e) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems ok for now, but probably it's better to classify isNotChanged via another subtype of VcsException or simply downgrade here to debug level.
|
Small typo in cbd1438: @juliabeliaeva Thank you for your PR, looks good to me! |
…after committing new file After a commit, GitStageLineStatusTrackerProvider#loadContent may be invoked while GitStageTracker statuses are not up-to-date yet. In particular, after committing a new file, its status can temporarily remain added, causing loadContent to return empty content. Once the status is refreshed, loadContent is not called again because the HEAD position has not changed, leaving base content outdated. This commit includes the file status in ContentInfo so that status changes can trigger a loadContent call. IJPL-181327 closes #3359 GitOrigin-RevId: 1eea8198563e897ecd91d28fdbe3ffb9ddaa48d1
…oaded for unchanged files IJPL-225212, IJPL-181327 When an added file becomes untracked again, it may be briefly reported as unchanged because GitUntrackedFilesHolder and GitStagingAreaHolder are refreshed independently. During this period GitStageLineStatusTrackerProvider can try to load base content and report a warning. This commit logs the condition at debug level instead to avoid polluting log files. closes #3359 GitOrigin-RevId: befcee2cfa6889f714bc9fb5533bfaf3f536e984
This PR provides fixes for the following issues:
The causes of both issues are related:
More details are in commit descriptions.