ClaudiaFang 4c8896b6fa fix: symlinked directories no longer break pull discovery ... A folder that's actually an OS symlink (e.g. a shared skills folder linked in from elsewhere) is a single git blob on the remote, not a real tree. Local scanning code that walked every subfolder returned by adapter.list() didn't know this, so it recursed straight into whatever unrelated directory the link pointed at: - GitignoreManager.scanDir() picked up bogus nested .gitignore paths under the linked folder and tried to fetch them from the remote repo, spamming 404s on every refresh (this matches the console errors in the issue's screenshot). - SyncStatusView's hidden-file scan recursed the same way instead of registering the symlink itself as a trackable path, so the folder never resolved to anything pullable — it just showed up as permanently "remote only". Both now check readLocalSymlinkTarget() before recursing into a folder and treat it as a single link entry instead, matching how file symlinks are already handled by the existing push/pull machinery. Also fixes createLocalSymlink() to pass the correct `type` hint to Node's symlinkSync on Windows — omitting it defaults to 'file', which produces a broken link when the target is actually a directory (a no-op on macOS/Linux, but required on Windows). Closes #33		2026-07-13 12:52:09 +00:00
..
logic	fix: symlinked directories no longer break pull discovery	2026-07-13 12:52:09 +00:00
services	fix(sync): clearer branch-not-found errors and connection test	2026-07-05 04:57:47 +00:00
ui	fix(compat): support Obsidian down to 1.11.0	2026-07-07 01:53:28 +00:00
utils	fix: symlinked directories no longer break pull discovery	2026-07-13 12:52:09 +00:00
setup.ts	fix: symlinked directories no longer break pull discovery	2026-07-13 12:52:09 +00:00