Backup about dotbot

[anishathalye]

Thanks for the suggestion!

Hmm, where should the backup file be backed up, ${file}.bak? What if that file exists already? We could back it up to ${file}.bak.${number}, but then that gets a bit ugly.

This seems to be a one-time thing per machine, and it should probably require user interaction (to merge information from old config files, etc) or at least alert the user. I'm not sure what's the best way of designing this feature. Maybe it's best to leave it up to the user, the way it is now?

[anishathalye]

I think this is best left to the user.

I'm going to go ahead and close it for now. Feel free to reopen it if you have any ideas.

[tukoz]

Voting for such a feature.
Existing dotfiles could be backed up in ~/.dotfiles-backup/, or ~/.dotfiles-backup/timestamp/ Allowing us to quickly set up our dotfiles, knowing we can easily check, merge and revert if needed.

[anishathalye]

Hmm, I guess we can reopen this issue.

I still don't know what the best way of handling this is. Would every file go to the backup folder? What if there are name collisions? Should the backup folder mirror the directory hierarchy instead?

I think there's some stuff to figure out before this could be implemented.

And as of now, I still think it's best left to the user -- in the majority of cases that I can think of, this isn't something that needs to be handled multiple times, and so it's probably handled best on a case by case basis anyways.

[tukoz]

A KISS proposal

• simply backup any replaced (aka deleted) dotfiles; eventually dropin directory hierarchy
• local, ie in $HOME out of the dotfiles dir.
• a backup-timestamp folder would avoid any filename collisions I can think of (unless server's a real mess :) Since it's a local folder

That only would add serenity, when eg in a hurry to deploy.

[anishathalye]

Let's leave this as-is for now.
I don't know if the hurry-to-deploy scenario happens often enough to warrant the additional complexity in the code.