Hacker News Reader

Comment by meowface | Hacker News Reader

>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.

View on HN

> 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

You can toss `git nomad sync` into a systemd timer (or cronjob if you prefer) and forget about it.

Same. 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.

Yep. 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.

Agreed 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.

Reply on news.ycombinator.com