[Filed by Copilot on behalf of @bghgary]
Problem
In GitHub Copilot app 1.1.14 on Windows, a folder project created at an empty path silently changes from folder to collection after a Git clone is placed in its root. The value is persisted as projects.container_kind; removing the clone or emptying the directory does not restore the project.
Reproduction
- Create a folder project at an empty directory and start a folder session successfully.
- Clone a Git repository into that project root.
- Remove the clone or empty the root.
- Start another folder session.
The dispatch fails with has no associated worktree, which points to a worktree problem rather than the project's changed classification. After backing up the database, restoring only the stored kind made the same project start folder sessions again without an app restart.
The failed dispatch also leaves a sidebar row that cannot be cleaned up normally: archive_session fails with fatal: not a git repository: (NULL), while delete_item reports success but leaves the row.
Expected
Adding a repository under a folder project should not silently change the project type. If conversion is intentional, the app should warn before changing it, identify that change when a folder dispatch is rejected, and allow the failed session row to be removed.
Related
github/app#1955 fixed folder-project creation selecting a nested .git directory in v1.1.7. This case happens after a valid folder project has already been created and used.
[Filed by Copilot on behalf of @bghgary]
Problem
In GitHub Copilot app 1.1.14 on Windows, a folder project created at an empty path silently changes from
foldertocollectionafter a Git clone is placed in its root. The value is persisted asprojects.container_kind; removing the clone or emptying the directory does not restore the project.Reproduction
The dispatch fails with
has no associated worktree, which points to a worktree problem rather than the project's changed classification. After backing up the database, restoring only the stored kind made the same project start folder sessions again without an app restart.The failed dispatch also leaves a sidebar row that cannot be cleaned up normally:
archive_sessionfails withfatal: not a git repository: (NULL), whiledelete_itemreports success but leaves the row.Expected
Adding a repository under a folder project should not silently change the project type. If conversion is intentional, the app should warn before changing it, identify that change when a folder dispatch is rejected, and allow the failed session row to be removed.
Related
github/app#1955 fixed folder-project creation selecting a nested
.gitdirectory in v1.1.7. This case happens after a valid folder project has already been created and used.