Prefer `git.path` VSC preference over Git on system path and enable portable mode

[myfonj]

This extension currently does not work with "portable" settings scenario: having stand-alone git executables unpacked on path referenced by git.path in VSCode enables VSC to perform common "native" Git operations as well as most other Git -related extensions.

Not having git executable in system's "%path%" currently yields

Command failed: git version 'git' is not recognized as an internal or external command, operable program or batch file.

error and makes this extension fail upon launch.

[github-actions[bot]]

Welcome!

Thank you for finding time to write an issue and help to make this extension better. I`ll appreciate if you find some time to rate this extension here.

I`ll get to this Issue ASAP.

[Serhioromano]

Looking into it.

[Serhioromano]

Thank you for pointing out this issue. I added check of git.path parameter. Also, I added git.path when there is no such a parameter. That is useful especially on Windows systems with CMD terminal.

Check version 1.3.1

Also, I'll very appreciate if you rate this extension here https://marketplace.visualstudio.com/items?itemName=Serhioromano.vscode-gitflow&ssr=false#review-details

[myfonj]

Not sure if I missed right version, but I'm still getting 'git' is not recognized as an internal or external command for any flow operation. I.e current v1.3.11 does not seem to heed neither VSC native git.path (pointing to git executable) nor gitflow.path pointing to usr\bin in git directory (but I don't see any real "flow executable" there, only configs and shell scripts or something).

Tried with vanilla portable profile of VSC insider build with config:

{
    "git.path": "<...>\\git-for-windows\\bin\\git.exe",
    "gitflow.path": "<...>\\git-for-windows\\usr\\bin\\"
}

(Config in is "portable" data folder that is next to code executable.)

VSC SCM actions like fetch work OK. Invoking git flow version (git from that git.path above) gives me 1.12.3 (AVH Edition).

Is there anything else I should set in some config?

[Serhioromano]

Try to empty both parameter. Your path looks strange. If you use WSL remote then path have to have / not\. And git.exe will not work when VS Code in WSL remote.

[myfonj]

Sorry, I didn't make it clear: that is literally content of the settings.json -- technically JSONC, you know, that file VSC shows if you invoke "Preferences: Open User Settings (JSON)" where all user settings are stored -- with unimportant pieces of paths collapsed to <…> (let's say D:\portable-programs) and escaped backslashes (JSON necessity).

As I suggested, I'm using the "portable mode" for storing user data and basically everything orchestrated in a portable manner (unpacked and configured to be using each other, so deleting the git.path would strip such VSC from all git features altogetger).

Full paths then look like:

• VSC executable: D:\portable-programs\VSCode-insider\Code - Insiders.exe
• VSC settings in data folder: D:\portable-programs\VSCode-insider\data\user-data\User\settings.json
• GIT executable (using cmder, keeping vendor\git-for-windows updated with recent release of PortableGit-<version>-64-bit.7z.exe): D:\portable-programs\cmder\vendor\git-for-windows\bin\git.exe

[Serhioromano]

if in terminal you run which git what do you get as return?

[myfonj]

Clean OS terminal has naturally no clue about git, until its executable path is added to environmental path (either by install or manually), what is not my case.

When I run where git in my portable, specifically configured cmder instance I get what I should:

λ where git
D:\portable-programs\cmder\vendor\git-for-windows\cmd\git.exe
D:\portable-programs\cmder\vendor\git-for-windows\mingw64\bin\git.exe

(it is added to its path by some init sctripts.) Same applies for terminal inside VSC, because is is configured to use the same thing.

When I invoke at VSCode native command Git: Show Git Output, it starts with

[2022-07-29T10:26:44.747Z] Log level: Info
[2022-07-29T10:26:44.805Z] [info] Validating found git in: D:\portable-programs\cmder\vendor\git-for-windows\bin\git.exe
[2022-07-29T10:26:44.858Z] [info] Using git 2.37.1.windows.1 from D:\portable-programs\cmder\vendor\git-for-windows\bin\git.exe
[2022-07-29T10:26:45.015Z] > git rev-parse --show-toplevel [151ms]
[2022-07-29T10:26:45.292Z] > git rev-parse --git-dir --git-common-dir [271ms]
[2022-07-29T10:26:45.295Z] [info] Open repository: ░░░░
[2022-07-29T10:26:45.408Z] > git status -z -uall [103ms]
(etc)

Presumably that's because of that git.path pref. Using other git-related extensions (notably GitLens or Git History) works as well. But admittedly, not all git-related extensions honour the git.path and work in portable mode.

[Serhioromano]

This for instance [2022-07-29T10:26:45.015Z] > git rev-parse --show-toplevel [151ms] say that it calls git with simply git command without path.

[myfonj]

This for instance [2022-07-29T10:26:45.015Z] > git rev-parse --show-toplevel [151ms] say that it calls git with simply git command without path.

Haven't dug into that much but I assume that it's that git mentioned on second and third line ("[…] found git in [path]", "[…]using git [version] from [path]"). That [path] coincidentally matches that one set by git.path preference.

[myfonj]

Seems there remains one bare git to be replaced by "${this.util.path}" in const checked = this.util.execSync(`git check-ref-format --branch ${name}`).trim();.

---

Also looking elsewhere it seems other extensions are waiting for "initialized" gitExt API state before relying on the executable path. (Vs yours. But IDK if that matters.)