5 ms·

He mentions three ways to irrevocably lose data. Is that really accurate? I would think old refs are still present in the repo and accessible from .git/logs, bu

He mentions three ways to irrevocably lose data. Is that really accurate? I would think old refs are still present in the repo and accessible from .git/logs, but I don't have any experience actually collaborating with git.

michaelmior 14y ago
You can solve the majority of such issues by disabling pushes to a remote repository. Assuming all developers collaborate through a central repository, disabling force push there should avoid commits being lost. In practice however, I've found a force push can be useful. For example, we once had a dev push code to our deployment branch which wasn't in fact ready for production. We could have just reverted all the commits which were added, but this would be messy and make merging again later painful. Instead, just `git reset --hard` to before the merge and force push. If you understand the implications of rebase and force push, you shouldn't have to worry about losing data.
ben_straub 14y ago
Rebasing isn't really destructive. Try it: open `gitk --all`, do a rebase -i and squash all the commits together, then switch back to gitk and refresh. You'll see all the old commits still in the database, but the HEAD and master branches point at the new commits. Totally not destructive, but it does take a bit of knowledge to undo the change. Git maintains what's called a "reflog" to help with this. It's a record of every place that every ref has ever pointed in your repository. Try it: `git reflog master`. You can even see when you did pulls, and what they merged in. The only truly destructive thing you can do to your git database is `git gc`.
- aneth4 14y ago
  > The only truly destructive thing you can do to your git database is `git gc`. And of course we should expect garbage collection to be destructive of information that is not garbage? Didn't know that? Just read the man page. Whoops, it doesn't actually mention that, but it does mention that it may happen automatically at times. So only clever people like you know archaic undocumented side effects of git's inscrutable design, except nobody ever really knows the full story because there is so much unnecessary crud to learn in addition. Clearly more can be destructive than gc if gc can be executed by other commands and triggers by repository state.
  - jeltz 14y ago
    git gc be default does only prune things older than 2 weeks so to lose your recently lost commits you would have to explicitly give a prune which is today. I do not think one can do this accidentally: git gc --prune=2012-08-05
  - makomk 14y ago
    The information is garbage - it's no longer referenced by the current state of the repository. "git gc" just delays collection in order to give users an opportunity to restore recently-unreferenced commits they decide they wanted after all. Also, the man page for "git gc" on my system describes exactly how long commits are kept around after they're no longer referenced, what this depends on, and how to change the default settings.

michaelmior 14y ago

You can solve the majority of such issues by disabling pushes to a remote repository. Assuming all developers collaborate through a central repository, disabling force push there should avoid commits being lost. In practice however, I've found a force push can be useful. For example, we once had a dev push code to our deployment branch which wasn't in fact ready for production. We could have just reverted all the commits which were added, but this would be messy and make merging again later painful. Instead, just `git reset --hard` to before the merge and force push. If you understand the implications of rebase and force push, you shouldn't have to worry about losing data.

ben_straub 14y ago

Rebasing isn't really destructive. Try it: open `gitk --all`, do a rebase -i and squash all the commits together, then switch back to gitk and refresh. You'll see all the old commits still in the database, but the HEAD and master branches point at the new commits. Totally not destructive, but it does take a bit of knowledge to undo the change. Git maintains what's called a "reflog" to help with this. It's a record of every place that every ref has ever pointed in your repository. Try it: `git reflog master`. You can even see when you did pulls, and what they merged in. The only truly destructive thing you can do to your git database is `git gc`.

aneth4 14y ago
> The only truly destructive thing you can do to your git database is `git gc`. And of course we should expect garbage collection to be destructive of information that is not garbage? Didn't know that? Just read the man page. Whoops, it doesn't actually mention that, but it does mention that it may happen automatically at times. So only clever people like you know archaic undocumented side effects of git's inscrutable design, except nobody ever really knows the full story because there is so much unnecessary crud to learn in addition. Clearly more can be destructive than gc if gc can be executed by other commands and triggers by repository state.
- jeltz 14y ago
  git gc be default does only prune things older than 2 weeks so to lose your recently lost commits you would have to explicitly give a prune which is today. I do not think one can do this accidentally: git gc --prune=2012-08-05
- makomk 14y ago
  The information is garbage - it's no longer referenced by the current state of the repository. "git gc" just delays collection in order to give users an opportunity to restore recently-unreferenced commits they decide they wanted after all. Also, the man page for "git gc" on my system describes exactly how long commits are kept around after they're no longer referenced, what this depends on, and how to change the default settings.