Skip to content

fix: change deprecated state.refs to getRefs()

Van Andersonrequested to merge
gitlab-community/gitlab-org/gitlab-vscode-extension:VanAnderson/fix-refs-deprecation into main
  • Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA

Description

Repository.state.refs has been deprecated in favor of Repository#getRefs. Not only that, but it appears to no longer be working correctly. We can see here that the getter for state.refs is now hard coded to return an empty array (L39): https://github.com/microsoft/vscode/blob/main/extensions/git/src/api/api1.ts#L39

The new method we should use can be found here (L1537-L1546): https://github.com/microsoft/vscode/blob/main/extensions/git/src/repository.ts#L1537-L1546. This newer method appears to return the same Ref[] type, so it should be a drop in replacement. I didn't try to transplant the typings for the arguments, but we have some extra functionality there if we ever want to reach for it.

Click to expand screenshot of debugging Screenshot_2024-08-12_at_10.16.29_PM

Related Issues

Relates to #1246

How has this been tested?

I ran the extension and poked around a bit. After debugging for a bit, I've found the only way to get to the code path for getTagsForHead is to be in a detached HEAD state with no tags on HEAD. In both places where getTagsForHead is called, we first check to see if there is a branch by using getTrackingBranchName; if there is a branch then we return before the call to getTagsForHead. I wouldn't have expected this, but when I check out a tag or even the commit the tag is on, getTrackingBranchName will return the tag name as if it were a branch.

vs-code-bug

What CHANGELOG entry will this MR create?

This won't fix anything quite yet. I'm going to follow up with some improvements the tree view and fetching logic that will build on this.

  • fix: Bug fix fixes - a user-facing issue in production - included in changelog
  • feature: New feature - a user-facing change which adds functionality - included in changelog
  • BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
  • None - other non-user-facing changes
Edited by Van Anderson

Merge request reports