Clones that were empty, cut off, or still ending are handled safely by the next sync #174

New Issue

2026-11-11T02:09:06Z

james.maes commented

2026-11-11 02:09:06 +00:00

What can go wrong today

Found in the review of the path-recovery work (#148) and deferred from it:

An empty clone's first checkout replaces what is in the folder. A repository that was empty when it was cloned gets its files on a later sync, with a forced checkout. A file the user put into that folder under a name the repository later uses is overwritten.
A first checkout that is cut off is reported as up to date. If that checkout is interrupted after its branch was created, the next sync sees an ordinary clone with nothing to pull and leaves the tree empty or half written.
An empty clone can wait for a branch that will never come. When the origin's first commit lands on another branch than the one the local HEAD names, the sync fetches it and checks nothing out, every time.
Two operations in one folder. A canceled sync stops waiting for its git operations but does not stop them; a clone that ends later cleans up by deleting its folder. Syncing again at once can start a second operation in the same folder.
A clone without .git/index fails with git's count of "conflicts" and no hint of what is wrong.
Clone in WSL clones straight into the destination: one that is cut off leaves a folder that the next attempt takes for a clone and tries to update.

Wanted

The first checkout refuses, before anything changes, when something of the user's is where the repository has a file or needs a folder.
The folder is marked unfinished before the branch is created, so the next sync completes it.
An empty clone follows the origin's default branch when the origin does not have the branch the local HEAD names.
One operation per folder in a process; the second is refused with a message that says to try again in a moment.
A message that names the missing index and how to rebuild it.
The WSL clone is made under a temporary name and moved into place when complete; old leftovers are removed, young ones are left (another gclo may be cloning).

## What can go wrong today Found in the review of the path-recovery work (#148) and deferred from it: 1. **An empty clone's first checkout replaces what is in the folder.** A repository that was empty when it was cloned gets its files on a later sync, with a forced checkout. A file the user put into that folder under a name the repository later uses is overwritten. 2. **A first checkout that is cut off is reported as up to date.** If that checkout is interrupted after its branch was created, the next sync sees an ordinary clone with nothing to pull and leaves the tree empty or half written. 3. **An empty clone can wait for a branch that will never come.** When the origin's first commit lands on another branch than the one the local HEAD names, the sync fetches it and checks nothing out, every time. 4. **Two operations in one folder.** A canceled sync stops waiting for its git operations but does not stop them; a clone that ends later cleans up by deleting its folder. Syncing again at once can start a second operation in the same folder. 5. **A clone without `.git/index`** fails with git's count of "conflicts" and no hint of what is wrong. 6. **Clone in WSL** clones straight into the destination: one that is cut off leaves a folder that the next attempt takes for a clone and tries to update. ## Wanted - The first checkout refuses, before anything changes, when something of the user's is where the repository has a file or needs a folder. - The folder is marked unfinished before the branch is created, so the next sync completes it. - An empty clone follows the origin's default branch when the origin does not have the branch the local HEAD names. - One operation per folder in a process; the second is refused with a message that says to try again in a moment. - A message that names the missing index and how to rebuild it. - The WSL clone is made under a temporary name and moved into place when complete; old leftovers are removed, young ones are left (another gclo may be cloning).

james.maes referenced this issue from a commit

2026-11-11 02:12:09 +00:00

fix(clone): clones that were empty, cut off, or still ending are handled safely by the next sync

james.maes referenced a pull request that will close this issue

2026-11-11 02:12:10 +00:00

fix(clone): clones that were empty, cut off, or still ending are handled safely by the next sync #175

james.maes referenced this issue from a commit

2026-11-11 02:40:47 +00:00

fix(clone): review of #175: nothing that is not gclo's is written over, by the first checkout or by its retry

james.maes referenced this issue from a commit

2026-11-11 03:24:28 +00:00

fix(clone): second review of #175: an unfinished checkout is recognised by its missing index and completed where it stands