4 ms·
>I also push often because I'm forever aware disks can fail. I'm not leaving a day's worth of work on my local drive and hoping it's there the next morning. I
by meowface 5y ago
>I also push often because I'm forever aware disks can fail. I'm not leaving a day's worth of work on my local drive and hoping it's there the next morning.
I separate file backup and version control. I keep every git repository I'm working on in Dropbox, and don't ever worry about how often I'm committing and pushing. I don't think git should be considered a substitute for a proper continuous backup system.
- jedberg 5y agoSame. I used to make a commit every time I got up so as not to lose work, but that just littered the history. Then I switched to keeping it in Dropbox or using Syncthing for work stuff, so now I only have to commit when I get to a stopping point or to share with others.
- meowface 5y agoYep. Dropbox is also a great safety net for when I mess something up in between commits. I've had a few times where I've deleted or changed some code that I couldn't restore just via undos. Normally I'd pretty much be screwed, but Dropbox retains a diff every time a file is saved, so it's basically impossible for me to lose anything.
- globular-toast 5y agoAgreed but pushing at least at the end of the day should be required just in case somebody needs to pick up your work for some reason.
- rraval 5y ago> I separate file backup and version control. I keep every git repository I'm working on in Dropbox, and don't ever worry about how often I'm committing and pushing. Motivated by a slightly different use case (seamless syncing across multiple machines), I built a custom tool that solves this concern within `git`: https://github.com/rraval/git-nomad https://github.com/rraval/git-nomad You can toss `git nomad sync` into a systemd timer (or cronjob if you prefer) and forget about it.