Comment by herogreen
7 years ago
In three years of using git I believe there is a single bad command that I could not undo: `git checkout -- somefile` The second worst thing I did is losing a commit in a `git rebase -i` but I was able to find it back with `git reflog`. Which makes me think that git is really well designed.
If by "designed" you mean "picking a content-addressable DAG as an underlying data structure", then yes, it is really beautiful. If you mean "provide a sane level of abstraction over said data structure", then hell no!
I think git provides a sane level of abstraction.
I don't think it provides the most consistent UI or helpful help, though. Once you move away from "learning git commands" to "learning how git works" and kind of figuring out which parts the commands refer to has helped also. That's still terrible though.
>I don't think it provides the most consistent UI or helpful help, though.
Understatement! Git is one of the most user-hostile tools I've ever seen. And I've used Sendmail.
1 reply →
Most of the abstraction is fine. The staging area model is a total mess though. The way that staging interacts with other commands (e.g. stash) is constantly surprising.
5 replies →
> I don't think it provides the most consistent UI
That reminded a video where Linus Torvals is been interviewed and he says that if he ever have to make good UI to get out of a desert island, he would die there.
http://stevelosh.com/blog/2013/04/git-koans/
I find the only people who find Git to be confusing or frustrating are the ones that try to adopt complex workflows. I've taught marketing and creatives to use Git with no issues.
Preach on brother!!!!!
Beautifully stated.
I recently had one of those holy-crap-what-did-I-just-do-I-lost-everything moments... But then realized that my scrollback had a list of files and my IDEs (PhpStorm and WebStorm) both kept _local_ revision histories and I was able to restore everything I had done.
I've been saved by the local history in IntelliJ more times than I would like to admit, heh.
I've had a few cases where I accidentally removed a local change before committing it; using Time Machine you can still recover some files then. I wish more editors had built-in support for it, if you're trying to restore a local file, macOS's TextEdit has support for Time Machine.
This combined with Time Machine backups means I haven't lost source in years.
Learning about the reflog just changed everything -- it removes all fear of "loosing" anything but uncommitted work.
In a similar vain to `git checkout`, `git reset --hard` is also an excellent way to loose uncommitted work.
When I know what file I'm missing a commit from, I usually end up using `git log` instead.
I accidently screwed up a rebase and dropped a test file. It managed to get merged as a blank file (always review after rebase!), I noticed a few days later when a PR was passing which I swore would of failed some tests I had written. Since then I couldn't exactly remember when I made the commit to the file, so trying to search through reflog became difficult. The above command makes it pretty easy as it will show you every change made to a file.
I'm a big fan of 'git checkout -p'. Even if you nuke a hunk you actually wanted, it's not actually gone until it falls off your scrollback buffer.
I go all in https://github.com/rroller/dotfiles/blob/master/bin/git-nuke
When in doubt either:
* commit to an itermediate branch as storage
* git stash && git stash apply (repeat last to recover stuff)
git stash pop is often nicer for temporary stuff.
The underlying system is well designed, but a user interface that allows you to get into a point where you can hose a repo is anything but.
The user interface should allow you to do anything you want, but warn you properly. In my experience, this is what git does if you’re about to do something dangerous.
How can you blame git for deleting stuff if you blindly pass --force to it?
you can always get back to what you had before unless you try really, really hard to destroy data
git reflog is your friend