Sourcetree Repository Restoration Interoperability with Git Metadata

Answer

Sourcetree cannot guarantee repository health from UI alone; it must rely on Git‑native verification commands to detect corruption, missing objects, or stale references after a restore.

Confirmed facts

• Sourcetree is a Git GUI; it shows a repository as long as the .git directory is readable, even if objects are missing or packs are corrupted.
• Integrity must be checked with Git commands such as git fsck, git rev-parse --verify HEAD, git status --porcelain=v2 --branch, git submodule status --recursive, and, when LFS is present, git lfs ls-files and git lfs fsck.
• Stale Sourcetree cache or worktree references are cleared by refreshing the repository or removing and re‑adding the bookmark.

Steps to verify after a restore

1. Open a terminal in the restored repository root.
2. Run git fsck --full and confirm there are no "missing", "corrupt", or "broken object" messages.
3. Run git rev-parse --verify HEAD and note the commit hash.
4. Run git status --porcelain=v2 --branch and compare the branch name and HEAD commit with what Sourcetree displays.
5. Run git submodule status --recursive; each line should start with a space (or the expected commit) – a leading "-" means uninitialized, "+" means a different checkout.
6. If LFS pointers exist (check for any .gitattributes lines with "filter=lfs" or look for .lfs files), run git lfs ls-files followed by git lfs fsck and verify all pointers resolve to local LFS content.
7. In Sourcetree, either press the repository’s refresh button or remove the bookmark and re‑add the repository; then confirm the UI matches the command‑line results (branch, commit, submodule state, LFS status).

Missing diagnostic detail

Do you have Git LFS pointers in the restored repository? If LFS is not used, the LFS verification steps can be omitted.