Detect and recover incomplete working trees after failed clones #46

New Issue

2026-07-14T17:42:18Z

KofTwentyTwo commented

2026-07-14 17:42:18 +00:00

(Migrated from github.com)

Problem

A failed clone attempts best-effort target-directory cleanup. If Windows permissions, antivirus, an open handle, or another filesystem condition prevents deletion, the partial target can retain a valid .git directory and an incomplete working tree.

On the next run, the engine treats any libgit-valid directory as an existing repository. Pull can then report the repository as up to date when the local and tracked tips match without proving that checkout completed, producing a false successful result for an incomplete working tree.

Evidence

Clone failure cleanup is attempted after checkout errors: gclo.Engine/LibGit2GitClient.cs:135-150.
Directory-deletion failures are swallowed: gclo.Engine/LibGit2GitClient.cs:553-570.
A libgit-valid directory is treated as an existing repository: gclo.Engine/OrgSyncEngine.cs:102-105.
Pull returns up to date from commit-tip equality without validating worktree completeness: gclo.Engine/LibGit2GitClient.cs:221-230.

This finding was independently verified at commit 119ac26804ef93b98a262cb1c0c7a41afe71fde5. It is related to the clone findings collected in #31, but is tracked separately because it can silently report incorrect success.

Acceptance criteria

An interrupted or failed fresh clone leaves durable state that distinguishes it from a completed clone, even when cleanup fails.
A later sync repairs the incomplete checkout or fails with an explicit actionable status; it never reports Done solely because commit tips match.
Successful clone completion clears any incomplete marker atomically.
Tests simulate a valid .git directory with an incomplete worktree and prove the next run does not return a false up-to-date result.
Existing Windows invalid-path recovery metadata remains compatible and is not mistaken for a generic incomplete clone.

## Problem A failed clone attempts best-effort target-directory cleanup. If Windows permissions, antivirus, an open handle, or another filesystem condition prevents deletion, the partial target can retain a valid `.git` directory and an incomplete working tree. On the next run, the engine treats any libgit-valid directory as an existing repository. Pull can then report the repository as up to date when the local and tracked tips match without proving that checkout completed, producing a false successful result for an incomplete working tree. ## Evidence - Clone failure cleanup is attempted after checkout errors: `gclo.Engine/LibGit2GitClient.cs:135-150`. - Directory-deletion failures are swallowed: `gclo.Engine/LibGit2GitClient.cs:553-570`. - A libgit-valid directory is treated as an existing repository: `gclo.Engine/OrgSyncEngine.cs:102-105`. - Pull returns up to date from commit-tip equality without validating worktree completeness: `gclo.Engine/LibGit2GitClient.cs:221-230`. This finding was independently verified at commit `119ac26804ef93b98a262cb1c0c7a41afe71fde5`. It is related to the clone findings collected in #31, but is tracked separately because it can silently report incorrect success. ## Acceptance criteria - An interrupted or failed fresh clone leaves durable state that distinguishes it from a completed clone, even when cleanup fails. - A later sync repairs the incomplete checkout or fails with an explicit actionable status; it never reports Done solely because commit tips match. - Successful clone completion clears any incomplete marker atomically. - Tests simulate a valid `.git` directory with an incomplete worktree and prove the next run does not return a false up-to-date result. - Existing Windows invalid-path recovery metadata remains compatible and is not mistaken for a generic incomplete clone.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KofTwentyTwo/gclo#46