You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(files): resolve a named append inside the chosen folder
cubic raised this twice; I deferred it once and it deserved the fix.
Append resolves a picked file by canonical id, where the folder beside it is
redundant. The advanced entry supplies a name instead, and a name is only unique
within a folder — a workspace-wide lookup takes the oldest match anywhere, so
the folder sat next to the field looking like it scoped the operation while
doing nothing. That is the same objection that had me remove this field earlier
in the branch, reappearing in advanced mode only.
The rule is now stated properly: the folder travels when it is what identifies
the file, and stays behind when the id already does. A named append expands the
chosen folder through the authorized use case, matches the name inside it, and
resolves by the id it finds — so no path-shaped reference is ever built and the
slash-in-a-folder-name hazard cannot arise on this path. A name that is not in
the folder refuses rather than reaching for a same-named file elsewhere.
Tests cover the case that motivated it: two files named notes.md in different
folders, appending to the one in the folder that was picked.
0 commit comments