Which Git executable should Sourcetree use by default for feature parity and stability?

Question

Sourcetree allows users to select between its bundled Git executable and the system-installed Git via Tools → Options → General, but Atlassian provides no definitive guidance on which choice best balances access to newer Git features against operational stability. The bundled Git in Sourcetree 4.x typically trails upstream releases by several versions, meaning capabilities such as experimental hash algorithms, performance improvements, or updated protocol support may be unavailable. Conversely, pointing Sourcetree at the system Git introduces variability: on Windows the system Git may come from Git for Windows, WSL, or a custom path, and its version can be outdated, missing, or configured with non-standard hooks that alter command behavior.

Switching the Git executable after repositories have been opened can change how commands like submodule updates, LFS filter processes, or merge strategies execute, potentially causing silent failures or inconsistent results across team members who have made different selections.

Does Sourcetree's bundled Git receive security backports promptly enough to justify staying on it? Which specific Git versions have been validated against each Sourcetree release? What criteria should teams use to decide between bundled and system Git in a mixed-environment workflow?

Tasadduq Burney · Answer

AnswerUse Sourcetree’s bundled Git executable as the default setting.Confirmed factsSourcetree ships with a version‑locked Git binary that is tested with each release.The bundled Git typically lags upstream by several minor releases, so newest features (e.g., SHA‑256 hashing) are absent.Atlassian’s guidance recommends keeping the bundled Git unless a specific system Git version has been validated for every team member.Likely explanation / trade‑offPointing Sourcetree at the system‑installed Git gives access to newer Git features, but the executable’s version, build options, and hooks can differ between Windows (Git for Windows, WSL, custom), macOS, and Linux. This variability can cause silent differences in submodule handling, LFS filter execution, or merge behavior across teammates.Steps to verify and decideOpen Sourcetree → Tools → Options → General and note the version shown for the bundled Git.In a terminal, run git --version to see the system Git version.If you consider switching, ensure every team member reports the same system Git version and identical configuration (e.g., core.autocrlf, LFS filters).Perform a quick sanity check: clone a test repository, fetch, push, and verify LFS/submodule behavior with both settings; the outputs should match.If the system Git versions differ or cannot be standardized, retain the bundled Git for stability.Missing diagnostic detailDo all team members use the same system Git version and configuration? If the answer is no, the bundled Git remains the safer default.

Which Git executable should Sourcetree use by default for feature parity and stability?

1 answer

Answer

Confirmed facts

Likely explanation / trade‑off

Steps to verify and decide

Missing diagnostic detail

Your perspective belongs here.

0 question comments