One idea I really like for avoiding VCS operation anxiety for beginners and experts alike is a filesystem layer that allows revert to any historical state. You just have your bash prompt output the current snapshot number, and then can use that as the revert target if there's a botched rebase or so. Unfortunately I do not know of a nicely packaged way to do this, or how to do it at all with OSS tools (but I bet it is feasible!).
> You just have your bash prompt output the current snapshot number, and then can use that as the revert target if there's a botched rebase or so.
That is what the ref-log is designed to do, but in my experience with git the risk is not about getting historical content, because git is very good about that: it's the current operation that's the risk
If I had any advice for beginners, it'd be to commit early and often, because git is disciplined about managing commits, but is a razor blade about anything in the working copy. There is no ref-log for "but I just typed that..." unless you told git to save it in something with a sha
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.
I've had VCS operation anxiety since the days of CVS. With Subversion it was largely a non-issue but Git made it return with a vengeance. This tool will presumably calm my frayed nerves.
If your fs already supports snapshots/versioning it might be convenient, but it doesn't solve the actual hard part which generally comes after changes have been merged upstream.
If we're only concerned with local changes I'd rather introduce beginners to `reset`, experts will already be doing something similar dependent on circumstance.
git reset --hard
git tag BEFORE
git reset --hard BEFORE
git reset --hard ORIG_HEAD
git reflog
git reset --hard HEAD@{<N>}
One idea I really like for avoiding VCS operation anxiety for beginners and experts alike is a filesystem layer that allows revert to any historical state. You just have your bash prompt output the current snapshot number, and then can use that as the revert target if there's a botched rebase or so. Unfortunately I do not know of a nicely packaged way to do this, or how to do it at all with OSS tools (but I bet it is feasible!).