4 ms·

It’s not helpful to say branches are only refs as a way of arguing branches don’t exist. But it is helpful in understanding how they work, what it means to pass

It’s not helpful to say branches are only refs as a way of arguing branches don’t exist. But it is helpful in understanding how they work, what it means to pass a branch argument to git for some operation. When I understood the reflog and how nothing I do is really gone (just gotta find it!), that was when I realized how much I like git.

littlestymaar 4y ago
> When I understood the reflog and how nothing I do is really gone (just gotta find it!), that was when I realized how much I like git. The reflog won't help you recover things in the staging area that where accidentally `reset --hard` though … (you can still get the ones you added to the index with `git add` but not committed[1], but changes that weren't added are lost for good) I love git, but the UX is still terrible … [1]: https://stackoverflow.com/questions/7374069/undo-git-reset-hard-with-uncommitted-files-in-the-staging-area https://stackoverflow.com/questions/7374069/undo-git-reset-h...
- draw_down 4y ago
  [dead]
- buck4roo 4y ago
  Why do you love it? It looks like you've described a tool with 1) a terrible UI, and 2) trains users to use commands that will eventually cause them to lose unsaved work.
  - littlestymaar 4y ago
    1. git has a terrible UX (not UI), including destructive actions without warning and much more really cumbersome things for newbies to learn about 2. once you know it enough, git is a powerful tool that I really appreciate. 1. and 2. aren't contradictory. And I would love git even more if the UX wasn't the dumpster fire it is, but I happen to know enough of its bad UX to be able to do what I want with it. Also, unlike the average git expert on HN, I still recognize that the UX is shit, and that you should need to spent as much time as I did in order to be able to use it at all. I'm really annoyed when people argue that a bad UX is in fact good because of some elitist reasoning.
  - draw_down 4y ago
    [dead]
- seba_dos1 4y ago
  The reflog also won't help you recover things you manually delete before you `git add` them. Or that were outside of the git repo. Or that you written on a piece of paper that you threw away. To someone who has a right mental model of git, all of these should be just as obvious. If you didn't stage your things, they were never in your repo.
  - littlestymaar 4y ago
    > Or that were outside of the git repo. Or that you written on a piece of paper that you threw away. Those aren't useful analogies as git cannot remove them in the first place. It's normal for a user to expect a tool to have an “undo” mechanism for its commands (with a prompt “this action is irreversible, do you want to proceed” for the rare actions where the action have to be destructive, like when running the git garbage collector manually) I know exactly why git behaves like it does, but that doesn't make its footgun less of a nuisance. And it's all about the UX, there's zero technical reason that would prevent git from saving your work as a temporary commit before deleting it, in a way that would make it recoverable, just a lack of user empathy.
    - OkayPhysicist 4y ago
      --hard is supposed to be your “this action is potentially lossy, do you want to proceed” acceptance. Same with --force. The problem is people teaching git, not git itself in this instance. Don't teach people to use git reset --hard, have them use named stashes. Easy recovery, same goal achieved.
      - littlestymaar 4y ago
        > have them use named stashes. Easy recovery, same goal achieved. It's absolutely not the same thing. If you just want to discard the modifications you have, then stashes are fine. But if you want to move a branch to another location, then you have to use reset --hard, and then when you have an unsuspected `git reset --hard` in your shell history, the shell auto-completion can screw you pretty quick. That's the difference between a prompt and a cli option, the first one doesn't appear in your shell history, so you're never going to have it pre-filled by mistake. > The problem is people teaching git, When you have a recurring problem with people teaching “something”, then the said “something” has a bad UX.

littlestymaar 4y ago

> When I understood the reflog and how nothing I do is really gone (just gotta find it!), that was when I realized how much I like git. The reflog won't help you recover things in the staging area that where accidentally `reset --hard` though … (you can still get the ones you added to the index with `git add` but not committed[1], but changes that weren't added are lost for good) I love git, but the UX is still terrible … [1]: https://stackoverflow.com/questions/7374069/undo-git-reset-hard-with-uncommitted-files-in-the-staging-area https://stackoverflow.com/questions/7374069/undo-git-reset-h...

draw_down 4y ago
[dead]
buck4roo 4y ago
Why do you love it? It looks like you've described a tool with 1) a terrible UI, and 2) trains users to use commands that will eventually cause them to lose unsaved work.
- littlestymaar 4y ago
  1. git has a terrible UX (not UI), including destructive actions without warning and much more really cumbersome things for newbies to learn about 2. once you know it enough, git is a powerful tool that I really appreciate. 1. and 2. aren't contradictory. And I would love git even more if the UX wasn't the dumpster fire it is, but I happen to know enough of its bad UX to be able to do what I want with it. Also, unlike the average git expert on HN, I still recognize that the UX is shit, and that you should need to spent as much time as I did in order to be able to use it at all. I'm really annoyed when people argue that a bad UX is in fact good because of some elitist reasoning.
- draw_down 4y ago
  [dead]
seba_dos1 4y ago
The reflog also won't help you recover things you manually delete before you `git add` them. Or that were outside of the git repo. Or that you written on a piece of paper that you threw away. To someone who has a right mental model of git, all of these should be just as obvious. If you didn't stage your things, they were never in your repo.
- littlestymaar 4y ago
  > Or that were outside of the git repo. Or that you written on a piece of paper that you threw away. Those aren't useful analogies as git cannot remove them in the first place. It's normal for a user to expect a tool to have an “undo” mechanism for its commands (with a prompt “this action is irreversible, do you want to proceed” for the rare actions where the action have to be destructive, like when running the git garbage collector manually) I know exactly why git behaves like it does, but that doesn't make its footgun less of a nuisance. And it's all about the UX, there's zero technical reason that would prevent git from saving your work as a temporary commit before deleting it, in a way that would make it recoverable, just a lack of user empathy.
  - OkayPhysicist 4y ago
    --hard is supposed to be your “this action is potentially lossy, do you want to proceed” acceptance. Same with --force. The problem is people teaching git, not git itself in this instance. Don't teach people to use git reset --hard, have them use named stashes. Easy recovery, same goal achieved.
    - littlestymaar 4y ago
      > have them use named stashes. Easy recovery, same goal achieved. It's absolutely not the same thing. If you just want to discard the modifications you have, then stashes are fine. But if you want to move a branch to another location, then you have to use reset --hard, and then when you have an unsuspected `git reset --hard` in your shell history, the shell auto-completion can screw you pretty quick. That's the difference between a prompt and a cli option, the first one doesn't appear in your shell history, so you're never going to have it pre-filled by mistake. > The problem is people teaching git, When you have a recurring problem with people teaching “something”, then the said “something” has a bad UX.