Comment by saila
4 years ago
I used to run a simple rsync script that copied all my active projects to an external drive every 15 minutes. I figured that if I had a major issue, I'd only lose a limited amount of work, which I could probably re-create without too much trouble.
Lately, I've been using private branches in the early stages of feature development, but you still have to remember to push in case of hardware failure. I also rely on my IDE's local history to get back to a good place if I need it.
I wonder if it would be good to combine these ideas: commit and automatically push every N minutes. Is this something that's being considered for Dura? Or is it a bad idea?
One big challenge must be avoiding commits when someone's right in the middle of typing, although having to stitch a couple adjacent commits together would definitely be better than losing work.
Automatic commits is generally not a good idea. Commits are supposed to be meaningful chunks of work, and meaning requires manual effort.
Automatic pushing is also probably not great. If it's just a backup mirror of some kind maybe, but otherwise you should be doing something like intentionally pushing what you're trying to share.
I don't really think that backups should be tied to git. There's already good backup software, wiring it into git doesn't seem to add anything.
For regular commits, sure, but for snap-shotting your work, I think it's fine. The backup branch would never be shared with anyone else, as you'd either push it to your own workspace/fork or to a clone on a mounted disk.
For this type of ephemeral backup of code-in-progress, I think storing it in git would be really convenient, because you'd just use standard git commands to find what you're looking for without having to deal with another tool.
Convenience could make it worth it. I can't say I'm all that convinced though, because you'll have to learn new concepts (and likely new commands, unless you're a git guru) about the backups anyway.