Okay, After I added the path above to the PATH env variable I worked with PowerShell that is installed from the Store.

Still, would be nice if PowerShell is included as an Option of Tools.

Thank you, Thomas, for the support

It did not work. What i am trying to escape is the space character in the path to the executable

The Tool window with the parameters

The error is

The command line that I used to test your approach with the new PowerShell from Run window is below, but it also did not work when i use in SmartGit

cmd.exe /c start C:\"Program Files"\WindowsApps\Microsoft.PowerShell_7.3.6.0_x64__8wekyb3d8bbwe\pwsh.exe -WorkingDirectory C:\Dev\Projects\oss\common

Cool, Thank you very much

That worked for me with a built-in version of PowerShell, However when I try to use the same way the new one (Installed from store), it fails. 

Maybe due to the double quotes used to escape the space character in the path.

Could you advise how to escape the space character in the Argument field in the Tool window?

The first approach was

• command: C:\Program Files\WindowsApps\Microsoft.PowerShell_7.3.6.0_x64__8wekyb3d8bbwe\pwsh.exe
  Arguments: -WorkingDirectory ${filePath}

After I tried different variations with cmd.exe using various /c, /k, start, and call variants, those failed to pass parameters correctly to the power shell, like the working directory.

Note that I use PowerShell installed from the Windows Store. But the same issue with the build-in version. But the parameters to set the working directory are different

Yes, I know that. 

However, there is "some logic?" behind how SmartGit starts a new shell process. While it works with cmd, it does not work with Power Shell.

I have tried to add a new entry to the tools to start PowerShell and it did not work. (PowerShell window does not show up and terminates immediately, while the same command line works fine from "Run" window).

I have upvoted the proposal change.

As you said it is almost impossible to catch up for the all Pull Request/Merge Request features different Git host providers would offer. Especially those which are available on the Internet.

However, in the corporate environment, it is not really the case. You have a stable, low paced version that is used across the company. Also, you have standard approach/Templates for how to fill the Pull Request. Having everything bundled in SmartGit is very convenient as you almost never should go to the Web UI in that case and SmartGit is just the only tool that you need to cover all specific GitOps.

But the options that you have proposed in a good alternative for like mine use cases I could keep what is there now (Minimal Options to fill the needed info into the Pull Request) and use Web UI redirection for all other cases, like Open Source project and/or usage of Git Hosting providers in the Internet.