|
A repository uses The underlying Git error is typically similar to: Why can this happen after the primary checkout is unlocked, and how can linked worktrees be configured to check out encrypted files reliably? |
Replies: 1 comment
|
Unlocking the primary checkout is necessary but not sufficient. A linked worktree has its own After unlocking the repository, run the following once from its primary checkout. It stores the commands in the clone-local Git configuration, so every linked worktree resolves the shared common directory: git config --local filter.git-crypt.smudge \
'GIT_DIR="$(git rev-parse --git-common-dir)" git-crypt smudge'
git config --local filter.git-crypt.clean \
'GIT_DIR="$(git rev-parse --git-common-dir)" git-crypt clean'
git config --local filter.git-crypt.required true
git config --local diff.git-crypt.textconv \
'GIT_DIR="$(git rev-parse --git-common-dir)" git-crypt diff'Then retry the T3 Code worktree thread. To verify independently, create a disposable linked worktree with This is a Git linked-worktree configuration issue rather than a T3 Code-specific encryption feature: T3 Code simply surfaces the failed |
Unlocking the primary checkout is necessary but not sufficient.
A linked worktree has its own
GIT_DIRunder.git/worktrees/.... Duringgit worktree add, Git runs thegit-cryptsmudge filter in that context. If the filter is configured as plaingit-crypt smudge,git-cryptlooks for the key in the linked-worktree metadata rather than the repository’s shared Git directory, and checkout fails before T3 Code can start the thread.After unlocking the repository, run the following once from its primary checkout. It stores the commands in the clone-local Git configuration, so every linked worktree resolves the shared common directory:
git config --local filter.git-crypt.smudge \ 'GIT_DIR="$(git…