Hacker News Reader

Comment by yeukhon | Hacker News Reader

For me the amazing thing about writing VCS is that a subtle bug or change could destroy someone's history and future commits. For example, in some old Mercurial release, hg mv had a bug (something affects history integrity) and the bug is fixed in recent release (the default version install on Ubuntu 12.04 should see that bug).

Maybe I lack of the domain knowledge, but writing VCS must be a very difficult task if you care about preserving history.

View on HN

Nothing unique about VCS. A subtle bug in a word processor has the potential to destroy someone's manuscript. A subtle bug in a payment processing system has the potential to expose a million credit card numbers. This is the nature of software.

No, it won't, because you keep your workstation backed up. You do keep a backup, right?

If you backup a git repository, that would be the same than making backup from a backup. How far would you go? :D Git repo itself is a backup!

No, your git repository is not a backup. It's a record of the history of your project, but it's not sufficient as a backup.

You could see pushing as making a backup, but even that wouldn't backup the exact state of your repository (private branches, configuration, reflog, rerere, etc..).

If an object gets corrupt, it's almost impossible to fix it, unless you have a copy of that object somewhere.

That's why it's still important to make backups of your repository.

I disagree. Even if you are a couple of commits behind, and you totally screwed, you should be able to recreate it from top of your head. maybe a couple of local git hooks, but still, if you pushed, the most important work should be available somewhere else and you can pull it.

That's assuming you routinely push all your changes and branches -- without exception -- to a server. Of course you can always pull from elsewhere to grab a copy of the repo, but that's no excuse for not backing up your local environment.

Reply on news.ycombinator.com