5 ms·

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 c

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.

anton_gogolev 9y ago
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!
- jimktrains2 9y ago
  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.
  - revmoo 9y ago
    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.
  - lmm 9y ago
    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.
    - jefurii 9y ago
      Git stage is "These are the things I'm planning to do", and git commit is "OK now do these things". Lots of carpenters draw plans before they start cutting but we don't think that's so hard do we? I had trouble with Git until I discovered "git add -p". I'll grant that Git could do with a revision of its commands and args.
      - lmm 9y ago
        > Git stage is "These are the things I'm planning to do", and git commit is "OK now do these things". Lots of carpenters draw plans before they start cutting but we don't think that's so hard do we? But when a carpenter stashes and unstashes their things, they don't suddenly find out they're magically planning to do a lot of things that they weren't previously planning to do.
        jefurii 9y ago
        Ha, that's a great way to put it. There's also "It is easy to shoot your foot off with git, but also easy to revert to a previous foot and merge it with your current leg" tho it's not quite as easy as the quote makes it out to be. Wish I knew who said that.
      - sirmarksalot 9y ago
        The issue isn't with the level of abstraction, but with the side-effect based workflow of some of the more common commands. The most visible of these is unstaging a file. The syntax is "git reset -- <file path>". What does that do? Well, it tells git not to change the head pointer. Of course, it wasn't going to do that anyway, but as a side effect of not doing anything, it makes a decision about what to do with all the staged files. The default resolution is to unstage everything so that everything that happened between the old head and the new head can go in the stage. When you add the "--", you're telling it to only apply that resolution to the specified files. So what you're actually telling Git is, "don't do anything, but when you don't do anything, move these files out of the stage so that you have room for all the files that you're not going to stage." And this is why I used Git for an entire year without actually knowing what "git reset" does.
        jefurii 9y ago
        I'll not argue with you that Git's syntax is weird. It's an airplane that was launched as a kite by Linus and then assembled into an airliner while in flight by the passengers. Could definitely do with a revision. The neat thing is that Git is an expression of that UNIX philosophy in which tools have various layers that are separated. You can have the crazy Git syntax but you can also write another command (or a GUI) that wraps Git and gives you the set of sane commands you wish it had, and which covers 90% of your use-cases, while still keeping the original around in case you need it. [Disclaimer: I've spent the past couple years doing exactly this (the GUI part) for a digital archives application. And to lmm's point up above my app does hide the staging step from the end-user.]
  - ivix 9y ago
    >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.
    - pqh 9y ago
      Just read the manual. https://git-scm.com https://git-scm.com
  - lhuser123 9y ago
    > 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.
  - hyperhopper 9y ago
    http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
- tonetheman 9y ago
  Preach on brother!!!!!
- _pmf_ 9y ago
  Beautifully stated.
0xcde4c3db 9y ago
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.
- ronnier 9y ago
  I go all in https://github.com/rroller/dotfiles/blob/master/bin/git-nuke https://github.com/rroller/dotfiles/blob/master/bin/git-nuke
jimktrains2 9y ago
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.
philjohn 9y ago
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.
- blibble 9y ago
  you can always get back to what you had before unless you try really, really hard to destroy data git reflog is your friend
- runeks 9y ago
  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?
nvahalik 9y ago
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.
- Cthulhu_ 9y ago
  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.
- maaaats 9y ago
  I've been saved by the local history in IntelliJ more times than I would like to admit, heh.
- nsxwolf 9y ago
  This combined with Time Machine backups means I haven't lost source in years.
Yokohiii 9y ago
When in doubt either: * commit to an itermediate branch as storage * git stash && git stash apply (repeat last to recover stuff)
- nathancahill 9y ago
  git stash pop is often nicer for temporary stuff.
humblebee 9y ago
When I know what file I'm missing a commit from, I usually end up using `git log` instead. git log -p --all --first-parent --remotes --reflog --author-date-order -- somefile 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.

anton_gogolev 9y ago

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!

jimktrains2 9y ago
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.
- revmoo 9y ago
  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.
- lmm 9y ago
  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.
  - jefurii 9y ago
    Git stage is "These are the things I'm planning to do", and git commit is "OK now do these things". Lots of carpenters draw plans before they start cutting but we don't think that's so hard do we? I had trouble with Git until I discovered "git add -p". I'll grant that Git could do with a revision of its commands and args.
    - lmm 9y ago
      > Git stage is "These are the things I'm planning to do", and git commit is "OK now do these things". Lots of carpenters draw plans before they start cutting but we don't think that's so hard do we? But when a carpenter stashes and unstashes their things, they don't suddenly find out they're magically planning to do a lot of things that they weren't previously planning to do.
      - jefurii 9y ago
        Ha, that's a great way to put it. There's also "It is easy to shoot your foot off with git, but also easy to revert to a previous foot and merge it with your current leg" tho it's not quite as easy as the quote makes it out to be. Wish I knew who said that.
    - sirmarksalot 9y ago
      The issue isn't with the level of abstraction, but with the side-effect based workflow of some of the more common commands. The most visible of these is unstaging a file. The syntax is "git reset -- <file path>". What does that do? Well, it tells git not to change the head pointer. Of course, it wasn't going to do that anyway, but as a side effect of not doing anything, it makes a decision about what to do with all the staged files. The default resolution is to unstage everything so that everything that happened between the old head and the new head can go in the stage. When you add the "--", you're telling it to only apply that resolution to the specified files. So what you're actually telling Git is, "don't do anything, but when you don't do anything, move these files out of the stage so that you have room for all the files that you're not going to stage." And this is why I used Git for an entire year without actually knowing what "git reset" does.
      - jefurii 9y ago
        I'll not argue with you that Git's syntax is weird. It's an airplane that was launched as a kite by Linus and then assembled into an airliner while in flight by the passengers. Could definitely do with a revision. The neat thing is that Git is an expression of that UNIX philosophy in which tools have various layers that are separated. You can have the crazy Git syntax but you can also write another command (or a GUI) that wraps Git and gives you the set of sane commands you wish it had, and which covers 90% of your use-cases, while still keeping the original around in case you need it. [Disclaimer: I've spent the past couple years doing exactly this (the GUI part) for a digital archives application. And to lmm's point up above my app does hide the staging step from the end-user.]
- ivix 9y ago
  >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.
  - pqh 9y ago
    Just read the manual. https://git-scm.com https://git-scm.com
- lhuser123 9y ago
  > 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.
- hyperhopper 9y ago
  http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
tonetheman 9y ago
Preach on brother!!!!!
_pmf_ 9y ago
Beautifully stated.

0xcde4c3db 9y ago

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.

ronnier 9y ago
I go all in https://github.com/rroller/dotfiles/blob/master/bin/git-nuke https://github.com/rroller/dotfiles/blob/master/bin/git-nuke

jimktrains2 9y ago

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.

philjohn 9y ago

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.

blibble 9y ago
you can always get back to what you had before unless you try really, really hard to destroy data git reflog is your friend
runeks 9y ago
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?

nvahalik 9y ago

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.

Cthulhu_ 9y ago
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.
maaaats 9y ago
I've been saved by the local history in IntelliJ more times than I would like to admit, heh.
nsxwolf 9y ago
This combined with Time Machine backups means I haven't lost source in years.

Yokohiii 9y ago

When in doubt either: * commit to an itermediate branch as storage * git stash && git stash apply (repeat last to recover stuff)

nathancahill 9y ago
git stash pop is often nicer for temporary stuff.

humblebee 9y ago

When I know what file I'm missing a commit from, I usually end up using `git log` instead. git log -p --all --first-parent --remotes --reflog --author-date-order -- somefile 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.