From the release reviews of 1.1.1 (2026-11-10). Not part of 1.1.1; planned for 1.2.0 unless said otherwise.
What happens
A repository's paths were resolved (a folder bad:dir renamed to bad_dir). Later the origin adds another path Windows cannot create under that folder (bad:dir/new:file.txt). The pull fails and offers to resolve it, but applying the suggested rename fails with the same message, and so does every later pull: the row stays failed until the folder is deleted. --sanitize-paths takes the same route.
The failure names the path as it would be written (bad_dir/new:file.txt); renames and skips are keyed by the path the repository has (bad:dir/new:file.txt). The Resolve dialog keys the same way, and a skip misses for the same reason.
Expected
The failure reports the repository's own path, so a rename or a skip of it applies.
Reproduced by a reviewer against fixture repositories. It is named in the 1.1.1 release notes as a known limit.
Re-verify against current main before working on it. A fix needs a regression test that fails without it.
From the release reviews of 1.1.1 (2026-11-10). Not part of 1.1.1; planned for 1.2.0 unless said otherwise.
## What happens
A repository's paths were resolved (a folder `bad:dir` renamed to `bad_dir`). Later the origin adds another path Windows cannot create under that folder (`bad:dir/new:file.txt`). The pull fails and offers to resolve it, but applying the suggested rename fails with the same message, and so does every later pull: the row stays failed until the folder is deleted. `--sanitize-paths` takes the same route.
The failure names the path as it would be written (`bad_dir/new:file.txt`); renames and skips are keyed by the path the repository has (`bad:dir/new:file.txt`). The Resolve dialog keys the same way, and a skip misses for the same reason.
## Expected
The failure reports the repository's own path, so a rename or a skip of it applies.
Reproduced by a reviewer against fixture repositories. It is named in the 1.1.1 release notes as a known limit.
Re-verify against current `main` before working on it. A fix needs a regression test that fails without it.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
From the release reviews of 1.1.1 (2026-11-10). Not part of 1.1.1; planned for 1.2.0 unless said otherwise.
What happens
A repository's paths were resolved (a folder
bad:dirrenamed tobad_dir). Later the origin adds another path Windows cannot create under that folder (bad:dir/new:file.txt). The pull fails and offers to resolve it, but applying the suggested rename fails with the same message, and so does every later pull: the row stays failed until the folder is deleted.--sanitize-pathstakes the same route.The failure names the path as it would be written (
bad_dir/new:file.txt); renames and skips are keyed by the path the repository has (bad:dir/new:file.txt). The Resolve dialog keys the same way, and a skip misses for the same reason.Expected
The failure reports the repository's own path, so a rename or a skip of it applies.
Reproduced by a reviewer against fixture repositories. It is named in the 1.1.1 release notes as a known limit.
Re-verify against current
mainbefore working on it. A fix needs a regression test that fails without it.