It isn't used in code and won't work at runtime anyway because there is no corresponding dependency in the plugin descriptor. This change is also necessary to avoid failures in the test which verifies dependencies (IJPL-171921).
GitOrigin-RevId: 2229953ded53a61b56e6865aa2b79a113502e6ee
Fixed only 1 part of the issue.
Seems that ETags don't work on our test tenant instance though.
This seems to be on the deployment side, but further investigation is needed.
GitOrigin-RevId: dcfad982e18d8489d7c60a39cb28118e5c92c395
This gets rid of the problem that the entire list was cleared upon re-opening the tool window.
That's a side-effect of using the 'cleverish' refresh from the generic list loader.
GitOrigin-RevId: 0c2fde9dab6dc4fa381ca9a0f89404f0abc5925a
reload -> to completely empty the list and start fresh (sometimes called force refresh?)
refresh -> may do a reload, but is allowed to be smarter
GitOrigin-RevId: 862795433e7245fc062ce14d235525853c03605e
#IJPL-183254 Fixed
The editor tab title-providing mechanism is a little wonky.
It relies on some check to see if the `getPath` method for Virtual files contains something that looks realish.
The one for GitHub turns out to look realish, but the one for GitLab does not.
Better not to rely on that and use the explicit mechanism.
See: com.intellij.openapi.wm.impl.PlatformFrameTitleBuilderKt.doGetFileTitle
GitOrigin-RevId: 24483266aa97cf81a1b0486eb41949681fe6fc49
#IJPL-182223 Fixed
We know for sure that .ghe.com links are resolvable (assuming the user is logged in), because .ghe.com domains are
(almost) always valid GitHub enterprise servers.
GitOrigin-RevId: fec4b0f5db3e26a6fc67f80e748bf3259562c5c6
GH decided to break links by having them repurposed as a deprecation warning.
Explicitly marking our query as 'advanced' is enough to ignore this.
#IJPL-180348 Fixed
GitOrigin-RevId: 3cee15779eacc58233a3b40b15aa61ff054a3891
What could happen is that one would set an account to default and
remove that account in the same transaction.
In that case, the default account would still be set and not checked.
We should probably remove or revise the notification completely,
since many things tend to work fine without an explicit default account.
#IJPL-73040 Fixed
GitOrigin-RevId: 40421b83468d0957d9ff1a238e52d3ad9f7d13c4
#IJPL-72847 Fixed
This makes sure that the multiline comment action is disabled
when any of the lines cannot be commented on.
Sadly GitHub is strict with this policy, so it's not avoidable, better to not let users start the process on such lines.
GitOrigin-RevId: 6e2ca4df2c1a84bede25ce34709d7ed303b36731
Didn't check every single usage, but in an ideal world,
this user should never leak into an API request.
Erroneous usages of the FAKE ghost user should be found when reported
and replaced with `null`, because in this case it's apparently
possible not to have a user assigned at all.
To be abundantly clear: this FAKE ghost user replaces github.com/ghost
in case one does not exist on the server.
GitOrigin-RevId: 6a1f48e6751992463cbe5c43b740ef2ab0f999fa
The existing gitlab.community and github.community modules that describe community versions of plugins with less functionality included do still exist intentionally. This is required for external developers to be able to build IDE from community project sources and get both plugins working there out of the box. Thus community plugins are still listed in IdeaCommunityProperties and PyCharmCommunityProperties. This part is only required for third-party folks. As for internal builds, they employ a build context produced by `org.jetbrains.intellij.build.IdeaUltimateBuilderKt.createBuildContextForCommunityProduct` which in turn prefers github.ultimate and gitlab.ultimate plugin distributions over community ones
GitOrigin-RevId: e8233c7133d63abe3aefa684cc57ed9bad9fee64
