Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FYI: badm fork #5

Open
waynr opened this issue Aug 31, 2022 · 0 comments
Open

FYI: badm fork #5

waynr opened this issue Aug 31, 2022 · 0 comments

Comments

@waynr
Copy link

waynr commented Aug 31, 2022

Hey there 👋

I found myself looking for a glorified symlink management tool (for dotfiles of course) a few weeks ago and came across your project.

I thought I would be able to add support for some behaviors I thought were missing from your implementation, but it turns out I didn't look close enough at how badm actually works to begin with. The baseline behavior actually didn't match up with how I manage my own dotfiles (using shitty 10+ year old bash scripts). So what I thought would be a few small changes turned more or less into a rewrite:

(after a certain point I just went ahead and renamed my fork since the baseline behavior is totally different now)

I thought you might be interested in a few bits though:

  • I have updated file move handling to rename files when they are detected as belonging to the same filesystem device.
    • If you think this is worth porting over to your own implementation you may find yourself wanting to support more than just linux as I have (i noticed you supported windows elsewhere).
  • The Config type now contains a vec of Dotfiles (thus supporting multiple dotfiles directories as well as multiple symlink directories).
  • I made use of types wrapping PathBuf to represent different types of directory and rely on initialization logic to more easily reason about paths in different places throughout the code
    • DotfilesDir to represent dotfiles directories
    • SymlinkDir to represent symlink directories
    • DotfilesPath to represent relative dotfile paths
      • being able to reliably know that a give path is relative helps avoid having to repeat path prefix checking/stripping in a bunch of different places

Anyway, thanks for the inspiration!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant