5 ms·

If your comment gets downvoted, it's much more likely to be because it is simply inaccurate. Git is remarkably safe out of the box. Git makes it damn near impo

If your comment gets downvoted, it's much more likely to be because it is simply inaccurate. Git is remarkably safe out of the box. Git makes it damn near impossible to lose anything other than intentionally. No matter if you rebase, reset --hard, or any other "destructive" operation, you can always get back to your prior state with nothing but a quick look in the reflog. Even if you start doing the really dangerous stuff like filter-branch, there again Git goes to pains to prevent you from losing data, by creating a refs/original folder to preserve your old refs (though you can also just use git fsck). Git goes above and beyond the call of duty when it comes to preventing data loss. Short of intentionally running the garbage collector with --prune=all right after rebasing, you won't lose data. As for the core concepts being the same, you're talking about usage whereas the person you quoted was talking about the actual implementation-level object model. Git's model is remarkably simple, and that simplicity is the source of many of its benefits. Every other VCS out there is more complex.

jlgreco 13y ago
To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard. Of course --hard is not on by default so... there is no issue here with git's default behaviour. > "Git's model is remarkably simple, and that simplicity is the source of many of its benefits. Every other VCS out there is more complex." Yup, exactly. The simplicity of git's model is hugely important. It allows me to not only know what git will or will not allow me to do (knowledge that in other systems is acquired by studying the docs for each particular command to see what all the flags do) but also lets me figure out what sort of novel operations are possible if I am willing to write a little code of my own. Example: Update hook that only allows a push if two or more colleagues of the committer have pushed annotations for that commit already? With little more than my knowledge of git's data model, and what update hooks are in the first place, I know that can be done and I know how I could do it.
- tednaleid 13y ago
  That's not correct, you can get back to any ref in the reflog, including those that you moved away from with git-reset --hard. Those commits are just dangling but are easy to get back to. I've got a presentation [1] that goes into how to use the reflog and how the various flags in reset work (among other things) that could explain more. [1]: http://tednaleid.github.io/showoff-git-core-concepts/ http://tednaleid.github.io/showoff-git-core-concepts/
  - jlgreco 13y ago
    My point is that git-reset --hard can remove data from the working tree filesystem that never hit the DAG in the first place: $ git init Initialized empty Git repository in /home/john/tmp2/.git/ $ echo "foo" > foo $ git add foo $ git commit -m 'init' [master (root-commit) 84fb5d1] init ... $ echo "bar" >>foo $ cat foo foo bar $ git reset --hard HEAD HEAD is now at 84fb5d1 init $ git reflog 84fb5d1 HEAD@{0}: commit (initial): init $ git status # On branch master nothing to commit (working directory clean)
    - tednaleid 13y ago
      Ok, yes, I agree with that clarification (and I missed that you specified in your original comment "uncommitted work", my mistake). If you git reset --hard and you have a dirty working directory, you can absolutely blow work away. That's one of the main reasons to use git reset --hard, but I agree that it needs to be used with intention. The easiest way to protect against it is to never use it if you have a dirty working directory, always commit first and then reset --hard after you've committed.
      - acjohnson55 13y ago
        I guess maybe the counterargument is that perhaps this should happen invisibly and automatically.
        skriticos2 13y ago
- fennecfoxen 13y ago
  I'd recommend learning "git reset --keep" instead of --hard because of this reason.
  - jlgreco 13y ago
    Certainly. --hard should only be used if you actually want what --hard provides.
- sampo 13y ago
  > To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard. Every version control system has a way to overwrite a dirty (modified) work directory, so git is hardly any more dangerous than any other tool. It also won't help you get back uncommitted files that you destroy with `rm`. No other tool does, either.
  - jlgreco 13y ago
    To be clear, I think that the behaviour of git-reset --hard is absolutely appropriate. I am just correcting the overly strong statement: "No matter if you rebase, reset --hard, or any other "destructive" operation, you can always get back to your prior state with nothing but a quick look in the reflog." There are situations that reflog won't get you back from, but those situations are perfectly logical and appropriate exceptions.
  - rocky1138 13y ago
    You can actually get back files that you rm. I've seen it done. Apparently it has something to do with unmounting the drive, restarting in single-user mode, then finding/knowing where it is on the drive before the OS overwrites it (hence the unmount).
    - TylerE 13y ago
      Doesn't generally work with modern FS's that use more "clever" allocation schemes.
      - willvarfar 13y ago
        Yeah there's not a lot of tooling for it. I recall writing my own to analyse a disk image to find traces of an intrusion, so its possible if you put in the leg work even for modern complex FS that do stuff like store small files inline in inodes.
      - Dylan16807 13y ago
        I'm not sure what you mean. The 'clever' filesystems I'm aware of are copy-on-write, which makes it much easier to recover deleted files. Unclever filesystems, like NTFS, are also quite easy to recover files on. I've had to do so multiple times.
- nbouscal 13y ago
  You're completely right, I should have clarified that I was only talking about committed data. My mistake.
jheriko 13y ago
Your definition of safe is not mine. I have no doubt the data is preserved - 'unrecoverable state' is too strong. Its not safe in the sense that if i make a change on submission day and need to revert it then its more complicated than it needs to be. Granted I should not be using something I don't have sufficient mastery of in that kind of scenario, but its not always so simple. My data being 'safe' is worthless if there is a steep learning curve to recovering it.
- nbouscal 13y ago
  The learning curve is not that steep. Compare it to learning vim or emacs, for example, and it's no contest. The learning curve is basically: 1) read Pro Git, 2) play with git for a little while. That's about it. If you can't afford that learning curve for something that is a core part of your workflow, you're doing something wrong.
jheriko 13y ago
I appreciate the effort you have made in trying to educate me here. I have recreated the problem I originally had and documented precisely why I think it really is a usability problem. Now that I have done this I am pretty sure that my anti-git sentiment is warranted - even if my initial comment was massively too harsh. http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html
- nbouscal 13y ago
  It looks like your troubles came purely from not understanding the concept of fast-forward merges. I completely agree with you that the documentation does not make this as clear as it ought to. However, the standard book on git (Pro Git, available free online) covers this (and most other git concepts) very well. This is simply a case of not understanding your tools (which you did acknowledge in the post). This is a widespread and deeply problematic situation, not just for version control systems but for almost all software, and it seems to only be getting worse. Takeaway lesson isn't that there's anything wrong with git, but rather that there's something wrong with an industry that seems to think we should be able to use tools without first learning how they work.

jlgreco 13y ago

To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard. Of course --hard is not on by default so... there is no issue here with git's default behaviour. > "Git's model is remarkably simple, and that simplicity is the source of many of its benefits. Every other VCS out there is more complex." Yup, exactly. The simplicity of git's model is hugely important. It allows me to not only know what git will or will not allow me to do (knowledge that in other systems is acquired by studying the docs for each particular command to see what all the flags do) but also lets me figure out what sort of novel operations are possible if I am willing to write a little code of my own. Example: Update hook that only allows a push if two or more colleagues of the committer have pushed annotations for that commit already? With little more than my knowledge of git's data model, and what update hooks are in the first place, I know that can be done and I know how I could do it.

tednaleid 13y ago
That's not correct, you can get back to any ref in the reflog, including those that you moved away from with git-reset --hard. Those commits are just dangling but are easy to get back to. I've got a presentation [1] that goes into how to use the reflog and how the various flags in reset work (among other things) that could explain more. [1]: http://tednaleid.github.io/showoff-git-core-concepts/ http://tednaleid.github.io/showoff-git-core-concepts/
- jlgreco 13y ago
  My point is that git-reset --hard can remove data from the working tree filesystem that never hit the DAG in the first place: $ git init Initialized empty Git repository in /home/john/tmp2/.git/ $ echo "foo" > foo $ git add foo $ git commit -m 'init' [master (root-commit) 84fb5d1] init ... $ echo "bar" >>foo $ cat foo foo bar $ git reset --hard HEAD HEAD is now at 84fb5d1 init $ git reflog 84fb5d1 HEAD@{0}: commit (initial): init $ git status # On branch master nothing to commit (working directory clean)
  - tednaleid 13y ago
    Ok, yes, I agree with that clarification (and I missed that you specified in your original comment "uncommitted work", my mistake). If you git reset --hard and you have a dirty working directory, you can absolutely blow work away. That's one of the main reasons to use git reset --hard, but I agree that it needs to be used with intention. The easiest way to protect against it is to never use it if you have a dirty working directory, always commit first and then reset --hard after you've committed.
    - acjohnson55 13y ago
      I guess maybe the counterargument is that perhaps this should happen invisibly and automatically.
      - skriticos2 13y ago
fennecfoxen 13y ago
I'd recommend learning "git reset --keep" instead of --hard because of this reason.
- jlgreco 13y ago
  Certainly. --hard should only be used if you actually want what --hard provides.
sampo 13y ago
> To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard. Every version control system has a way to overwrite a dirty (modified) work directory, so git is hardly any more dangerous than any other tool. It also won't help you get back uncommitted files that you destroy with `rm`. No other tool does, either.
- jlgreco 13y ago
  To be clear, I think that the behaviour of git-reset --hard is absolutely appropriate. I am just correcting the overly strong statement: "No matter if you rebase, reset --hard, or any other "destructive" operation, you can always get back to your prior state with nothing but a quick look in the reflog." There are situations that reflog won't get you back from, but those situations are perfectly logical and appropriate exceptions.
- rocky1138 13y ago
  You can actually get back files that you rm. I've seen it done. Apparently it has something to do with unmounting the drive, restarting in single-user mode, then finding/knowing where it is on the drive before the OS overwrites it (hence the unmount).
  - TylerE 13y ago
    Doesn't generally work with modern FS's that use more "clever" allocation schemes.
    - willvarfar 13y ago
      Yeah there's not a lot of tooling for it. I recall writing my own to analyse a disk image to find traces of an intrusion, so its possible if you put in the leg work even for modern complex FS that do stuff like store small files inline in inodes.
    - Dylan16807 13y ago
      I'm not sure what you mean. The 'clever' filesystems I'm aware of are copy-on-write, which makes it much easier to recover deleted files. Unclever filesystems, like NTFS, are also quite easy to recover files on. I've had to do so multiple times.
nbouscal 13y ago
You're completely right, I should have clarified that I was only talking about committed data. My mistake.

jheriko 13y ago

Your definition of safe is not mine. I have no doubt the data is preserved - 'unrecoverable state' is too strong. Its not safe in the sense that if i make a change on submission day and need to revert it then its more complicated than it needs to be. Granted I should not be using something I don't have sufficient mastery of in that kind of scenario, but its not always so simple. My data being 'safe' is worthless if there is a steep learning curve to recovering it.

nbouscal 13y ago
The learning curve is not that steep. Compare it to learning vim or emacs, for example, and it's no contest. The learning curve is basically: 1) read Pro Git, 2) play with git for a little while. That's about it. If you can't afford that learning curve for something that is a core part of your workflow, you're doing something wrong.

jheriko 13y ago

I appreciate the effort you have made in trying to educate me here. I have recreated the problem I originally had and documented precisely why I think it really is a usability problem. Now that I have done this I am pretty sure that my anti-git sentiment is warranted - even if my initial comment was massively too harsh. http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

nbouscal 13y ago
It looks like your troubles came purely from not understanding the concept of fast-forward merges. I completely agree with you that the documentation does not make this as clear as it ought to. However, the standard book on git (Pro Git, available free online) covers this (and most other git concepts) very well. This is simply a case of not understanding your tools (which you did acknowledge in the post). This is a widespread and deeply problematic situation, not just for version control systems but for almost all software, and it seems to only be getting worse. Takeaway lesson isn't that there's anything wrong with git, but rather that there's something wrong with an industry that seems to think we should be able to use tools without first learning how they work.