The complete user data hasn't been proven useful.
It is not part of the license data per se, but only relevant to the request.
GitOrigin-RevId: 4c75b9f2eb6f36fb512bcd2e5622259db45310c4
A dialog asking a user to give consent to use a third-party plugin cannot be shown in remote dev mode because the platform isn't fully loaded at that moment, and the connection is not initialized yet. So to avoid exceptions, now in such cases third-party plugins are automatically disabled, and a warning is printed to the log with a suggestion about using a new '--give-consent-to-use-third-party-plugins' option in the 'installPlugins' command (see IJPL-162211).
GitOrigin-RevId: 62907bd7c9e70e37278f3699c550852ed0790a23
Before, if 'installPlugins' commands installs a third-party plugin, it recorded its ID in a file, and the next time the IDE is started, it asks a user for confirmation. It was inconvenient because if an IDE installation is prepared by scripts, it isn't expected that the user needs to confirm something manually. Also, the confirmation window is shown during an early phase of the startup, and it cannot be shown to the user in remote development mode (see GTW-9680).
So now a new option '--give-consent-to-use-third-party-plugins' for the 'installPlugins' command is supported. If it's specified, it automatically marks installed third-party plugins as approved.
GitOrigin-RevId: 812ce8be018b722a5c676fb879234ef1e3e80bdb
This is needed to make it simpler to add a new option to the 'installPlugins' command (IJPL-162211).
GitOrigin-RevId: 2a154e838c5e3d132ba0b48cb95dc63f113ac995
Also, this fixes a race exception at the block terminal startup (EA-1466837), because after the fix `FileTypeManager` doesn't know about `TerminalPromptFileType`.
GitOrigin-RevId: 4c049cfb5e2065a96177c7578b79034fb89e259b
After some optimizations, for the sake of performance, a matcher stopped matching anything for long patterns. Keeping this optimization, now we fall back to the regular matcher to match at least something, even without tolerance to typos
GitOrigin-RevId: 8c3be92bccd5eb6e382df32394cc27f95113e3e4
We must visit the Swing model there because we don't just do it to collect
paths to select. We also must make sure that the collected paths become
known to the Swing model, because it'll be impossible to actually select
them otherwise.
Alternatively, we could collect the paths first, and then perform selecting
and expanding using another visitor, which would be visiting the Swing
model, but it would be a more complicated solution with no added benefits.
We're already visiting the model, so it's best to do everything in one go
and then just let Swing to do its job without any more background stuff.
GitOrigin-RevId: fc4d2871d92fbc1cc0316c06f7faa41cf27e225f
There's a special logger for Select in Project View functionality.
It was already used in trySelect, but not in select. Fix that.
GitOrigin-RevId: 5946e3195107e85a5ac865073486f486d14972fa
It's duplicated by `GitCheckoutAction`.
However, keep `CheckoutAction#checkoutBranch` and `CheckoutRemoteBranchAction#checkoutRemoteBranch` marking them for removal
GitOrigin-RevId: 299ae1346bd3e973300819c41f2dcb95385c4eee
