|
|
|
|
|
by mgsloan2
1239 days ago
|
|
Yeah, but ref-log is scary to beginners (I suppose rebase is too!). Rebase was a poor example, but even so, it is way easier to copy a snapshot number out of your cli and restore than it is to dig through your reflog for the right sha ref-log doesn't save you in so many situations. As you point out, you have to commit all the time for it to save you. Even then, git repo corruption is possible and then you are hosed. For example: * a hard reset clears your working copy changes * you pop a stash you didn't mean to, atop your working copy changes. Now your working copy changes are intermixed with the stash and you have to manually decouple them. * you accidentally stage hunks to your index and its tricky to unstage them because they are adjacent to other hunks Such a tool also saves you from accidentally saving over your work in the text editor. It generally makes it so that you don't need to be as careful. So, generally, git commands that affect your working copy are not undo-able and can be very time consuming to undo if you have no proper time machine underneath your repo. I happily have experienced the bliss of having this reassurance, but it is only within a proprietary env. |
|