Which SourceTree Git Engine Should Handle Current Authentication and Repository Features?
0 reputation · 03 Oct 2022, 15:32 UTC
0 reputation · 03 Oct 2022, 15:32 UTC
SourceTree includes an Embedded Git engine so the application functions immediately after installation, while a System Git option lets the GUI use the operating system's Git binary. The choice is made in the application's Git options and applies per installation rather than rewriting repository-level configuration. However, switching engines does not automatically update global Git configuration, so credential helpers, signing keys, and external tool paths may need separate validation.
Because the bundled Embedded Git version and the system Git version can differ depending on the SourceTree release and operating system package cadence, it is unclear what concrete signals indicate that Embedded Git is genuinely insufficient. Some workflows, such as Git LFS or submodule operations, may behave differently under each engine, but the exact threshold where those differences become blocking is uncertain.
Which practical criteria should determine whether Embedded Git remains adequate for a given repository and hosting provider? What version comparison or workflow test reveals a real limitation without relying on assumptions about bundled versus system binaries? When is it safer to stay with Embedded Git despite a newer system version being available?
33775 reputation · 04 Oct 2022, 02:57 UTC
Keep Embedded Git unless a side-by-side test shows it cannot complete a required repository operation. A newer system Git version is not, by itself, a reason to switch. The deciding evidence is identical fetch, push, LFS, submodule, and signed-commit checks run in SourceTree's built-in terminal under each engine.
Repeated authentication prompts after an engine change usually mean a credential helper configured for one engine is invisible to the other. Signed-commit failures often point to absolute GPG or signing-program paths that differ between engines. These are configuration mismatches, not evidence that one engine is inherently better.
git version.git lfs pull if LFS is used, git submodule update --init if submodules are used, and create one signed commit if signing is required.If both engines pass the same tests, stay with Embedded Git for reproducible team behavior. Switch only when the current engine provably lacks a required transport, credential path, or external tool.
This assumes a standard SourceTree installation with a functional bundled engine. The exact LFS and helper tools bundled with Embedded Git vary by release and operating system, so version numbers should be read from SourceTree rather than assumed. Current verification is required; treat this as a draft pending confirmation of your SourceTree version, operating system, and hosting provider.
Missing diagnostic detail: which authentication method the repository uses—HTTPS with a credential manager, SSH keys, or tokens—because that determines whether engine choice materially changes authentication behavior.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.