Feature request: Symlink-based profile switching for config directories

[bjesuiter]

I have a setup where I use Bridle to manage OpenCode configuration profiles. My configuration directory (~/.config/opencode) is managed through a dotfiles repository using stow.

Current situation:

• Bridle stores profiles in a dedicated directory (e.g., ~/.config/bridle/profiles/)
• Each profile contains OpenCode configuration
• ~/.config/opencode should point to the currently active profile

Symlink structure:

~/.config/                          # stow symlinks → ~/jb-home/home/.config/
└── opencode/                       # current active profile
    ├── config.json
    └── ...

~/.config/bridle/profiles/          # profile storage (under git in jb-home)
├── default/
│   ├── config.json
│   └── ...
├── work/
│   ├── config.json
│   └── ...
└── personal/
    ├── config.json
    └── ...

The problem:

1. When ~/.config/opencode is a regular directory under git control, every profile change results in git detecting changes and creating commits for the same files repeatedly.

2. When ~/.config/opencode is a symlink to the profile directory, Bridle's smart detection of config updates sees the symlink change and interprets this as the user having modified the configuration externally. It then deletes its own profile files when trying to sync, causing data loss.

Desired behavior:
When the OpenCode config directory is a symlink, Bridle should:

• Detect that it's a symlink
• Simply replace the symlink target when switching profiles
• Not attempt to sync or compare contents with the profile storage
• Keep the actual profile data safely stored in its profile directory

Proposed solution:
Add an option to enable "symlink mode" for config directories. When enabled:

1. Bridle checks if the config directory is a symlink
2. If so, instead of syncing/copying files, it just updates the symlink target
3. This keeps git history clean (all changes happen in the profile storage directory)
4. No risk of Bridle deleting profile data due to external changes

This would be useful for anyone using:

• Stow or similar dotfile managers
• Git-controlled configuration repositories
• A setup where the config directory needs to be shared or symlinked

Would this feature be feasible to implement? I'm happy to discuss further or contribute if guidance is provided.

[bjesuiter]

Sorry for generating this issue with ai, it's really late here in germany and i have to go to bed 🙈
If you have problems to understand what I mean, please ask, I'm gladly going to explain it to you in detail!

If you don't feel that this is a problem for you, then I'd code a solution myself, but wanted to ask first if you want the contribution upstream :)

[Marsipanes]

Using bridle with dotfile managers like stow is definitely a valid use case, and the data loss issue you described when switching symlinks sounds critical to avoid.

Your proposed "symlink mode" seems like the correct solution here. Instead of syncing file contents, just updating the symlink target would be much cleaner for this workflow.

[bjesuiter]

Are you maintainer of this or only "random" commenter? Need to decide to see this as a "contribute a fix" or "simple encouragement"

Anyways, thanks for the support and idea validation! ✨

[neiii]

hey, will take a look during the upcoming week. had exams.