Summary
extract_repos() / expand_dir() resolve a relative workspace root against the process working directory (cwd defaults to pathlib.Path.cwd), not against the directory the config file lives in. So a workspace root written as ./vendor/ means a different destination depending on where the command is invoked from.
Why it matters more now
When configs came only from ~/.vcspull.yaml and the XDG directory, relative roots were unusual and the ambiguity rarely surfaced. Once vcspull reads project configs discovered by walking up from the cwd, an ancestor's .vcspull.yaml containing ./vendor/ resolves against wherever you happen to stand, not against that config's own directory — so the same file materializes repositories in different places from different subdirectories. It also makes an override count reported by config ls shift with cwd.
Expected
A relative workspace root in a config file should resolve against that file's directory, so a project config means the same thing regardless of which subdirectory the command runs in. This mirrors how tools like git, eslint, and mise treat paths declared in a discovered config.
Notes
This is pre-existing behavior, not a regression — filing it because the configuration-scopes work makes discovered ancestor configs a normal case, which turns a latent sharp edge into one users will hit. A fix should thread the config file's own directory as the resolution base for entries that came from that file, while leaving --file and home-scope behavior unchanged.
Summary
extract_repos()/expand_dir()resolve a relative workspace root against the process working directory (cwddefaults topathlib.Path.cwd), not against the directory the config file lives in. So a workspace root written as./vendor/means a different destination depending on where the command is invoked from.Why it matters more now
When configs came only from
~/.vcspull.yamland the XDG directory, relative roots were unusual and the ambiguity rarely surfaced. Once vcspull reads project configs discovered by walking up from the cwd, an ancestor's.vcspull.yamlcontaining./vendor/resolves against wherever you happen to stand, not against that config's own directory — so the same file materializes repositories in different places from different subdirectories. It also makes an override count reported byconfig lsshift with cwd.Expected
A relative workspace root in a config file should resolve against that file's directory, so a project config means the same thing regardless of which subdirectory the command runs in. This mirrors how tools like git, eslint, and mise treat paths declared in a discovered config.
Notes
This is pre-existing behavior, not a regression — filing it because the configuration-scopes work makes discovered ancestor configs a normal case, which turns a latent sharp edge into one users will hit. A fix should thread the config file's own directory as the resolution base for entries that came from that file, while leaving
--fileand home-scope behavior unchanged.