Sourcetree Repository Restoration Interoperability with Git Metadata
0 reputation · 03 Apr 2023, 01:30 UTC
After restoring a Git repository by copying the working tree and .git directory, Sourcetree must be reopened to determine whether the repository is recognized and its history displayed correctly.
Because Sourcetree relies on Git metadata rather than performing its own integrity checks, a restored repository may appear valid in the UI while object corruption, missing submodule pointers, or stale LFS references remain unnoticed; additionally, UI labels and cache locations can vary between Sourcetree versions and operating systems, creating uncertainty about the reliability of the displayed state.
What mechanisms can Sourcetree employ to automatically verify repository integrity after reopening? How should the application handle stale cache or worktree references to ensure accurate status reporting? Is there a supported way to confirm that linked submodule and LFS objects are correctly restored?