5 ms·

Can't be he's using it wrong.

peteradio 4y ago
No kidding, what exactly is problem? Probably merge conflicts on binary blobs or some stupid shit. Clunky, it is not. What was this guy using before? SVN!? That shit was go get a coffee or lunch slow.
- pxmpxm 4y ago
  > Clunky, it is not. I want to roll back an accidental commit of an extra file to the previous, uncommitted state. Or even simpler, undo a commit to restore the exact state just before it happened.
  - alrlroipsp 4y ago
    git reset --soft HEAD~1 git status ..remove files that was to be commited.. git commit -m "previous message"
    - pxmpxm 4y ago
      Uh huh, now imagine you've built something with usage in mind, rather than a hodgepodge of leaky abstractions for what's happening behind the scenes: git undo git undo file
      - RHSeeger 4y ago
        This right there is the what gives me pause. Every time I need to do something out of the box, I need to start googling. Rather than there being an easy to remember command to do it, one that has a good name that indicates what it does; or, more specifically, what one uses it to accomplish. It's like naming a field "list" in code; I know it's a list... but name it so I know what is in it or what it's for. And to add to the fun, there's multiple other answers in this thread on how to accomplish the same task.
      - iam-TJ 4y ago
        git reset --soft HEAD^ # make changes so index only contains what you want git commit -a -C ORIG_HEAD of if you prefer: git config --global alias.undo reset --soft HEAD^ git config --global alias.redo commit -a -C ORIG_HEAD then: git undo # make changes so index only contains what you want git redo You could use -c (--reedit-message=) instead of -C (--reuse-message=) for further flexibility. ORIG_HEAD is set to point to the most recent HEAD when using reset. See "man git-reset" > EXAMPLES > "Undo a commit and redo".
  - peteradio 4y ago
    git checkout prior_commit_hash "file_path"
    - WillDaSilva 4y ago
      Likely followed by git commit --amend
  - eurasiantiger 4y ago
    > undo a commit git reset --hard HEAD^ Which makes perfect sense once you know that you are not ”undoing a commit” inasmuch as you are resetting the most recent state of an index to the second most previous one. Just make an alias for it if it bothers you, that’s what is generally recommended by unix beards for hard to remember but oft-used commands anyway.
    - pxmpxm 4y ago
      >once you know that you are not Making my point for me - the usage is "undo a commit" or "undo a file accidentally added to a commit", what you mentioned are implementation details that are leaking up to the interface. If I'm doing cp file newFile, I don't need to know anything about ext3, APFS or anything about hard drives to operate on files.
      - Brian_K_White 4y ago
        Isn't "undo" too ambiguous to be useful? Or do you imagine it as a subcommand with further parameters to describe what to undo and how? I think a term like undo is a mistake if you think of the git history like accounting. There is, or there should be, no such thing as undo the way an unsophisticated layperson imagines they want. Instead undos are just changes like any other changes. You don't fix entry errors by actually editing history, you make a new entry that both reverses the error and explains why. If that leads to having to think about some problems a bit non-intuitively, I'm pretty tempted to just say tough shit, it's worse to try to simplify something if simpler really only means wrong and incomplete. Perhaps undo was just a bad example of a git failing. There certainly are commands that could be more scrutable without becoming incomplete or wrong. But I only see it as an unavoidable process of development. It's not possible for anything to spring forth fully baked, and so it's pointless and wrong to complain that it didn't happen. So the crappiness of the early versions (of whatever, in general, not git in particular) is not damning and nothing else can ever be any different. Then the next, almost as unavoidable, at least certainly natural and typical, is that the process of imporoving necessarily means changing, and that leads to both redundancy and inconsistency. 4 different ways to do something because there is the old way and the next way and the next way... I see only that git could improve some things in only the way is unavoidable and applies to everything everywhere, and is not a special git failing but simply life, and that most of the perceived complexity of git comes straight from the underlying job we need it to do. It may not be logically possible to have a fundamentally simple tool to do this complex job, only a simple tool that only actually does a simple job, which isn't good enough. The best I even consider to wish for is just improvement over time figuring out more consistent interfaces and improving the predictability so that you can be more confident in understanding "when I say X, what will actially happen?".
  - throw_nbvc1234 4y ago
    git reflog --help Probably not what you want to use day to day but if you want to undo things i find reflogs better then commits for tricky situations.
  - phone_book 4y ago
    I love how this got 4 different answers.
    - pxmpxm 4y ago
      The question was intentionally crafted for that effect :)
    - peteradio 4y ago
      2 answers the same and rolling back all files. 1 answer for rolling back single file. 1 non-solution. The OP has a poorly defined use case for "undo" (which commit? all files or one?) and can easily wrap whichever suits their need in an alias.
- UncleMeat 4y ago
  Git was designed for a fully distributed open source environment where there is no canonical head and no continuous access to a source repository. It makes sense for the way that linux is developed. It makes less sense for the way that most corporate development is done. Yes, SVN is worse. That doesn't mean that git has flaws in its most common deployment.

No kidding, what exactly is problem? Probably merge conflicts on binary blobs or some stupid shit. Clunky, it is not. What was this guy using before? SVN!? That shit was go get a coffee or lunch slow.

pxmpxm 4y ago
> Clunky, it is not. I want to roll back an accidental commit of an extra file to the previous, uncommitted state. Or even simpler, undo a commit to restore the exact state just before it happened.
- alrlroipsp 4y ago
  git reset --soft HEAD~1 git status ..remove files that was to be commited.. git commit -m "previous message"
  - pxmpxm 4y ago
    Uh huh, now imagine you've built something with usage in mind, rather than a hodgepodge of leaky abstractions for what's happening behind the scenes: git undo git undo file
    - RHSeeger 4y ago
      This right there is the what gives me pause. Every time I need to do something out of the box, I need to start googling. Rather than there being an easy to remember command to do it, one that has a good name that indicates what it does; or, more specifically, what one uses it to accomplish. It's like naming a field "list" in code; I know it's a list... but name it so I know what is in it or what it's for. And to add to the fun, there's multiple other answers in this thread on how to accomplish the same task.
    - iam-TJ 4y ago
      git reset --soft HEAD^ # make changes so index only contains what you want git commit -a -C ORIG_HEAD of if you prefer: git config --global alias.undo reset --soft HEAD^ git config --global alias.redo commit -a -C ORIG_HEAD then: git undo # make changes so index only contains what you want git redo You could use -c (--reedit-message=) instead of -C (--reuse-message=) for further flexibility. ORIG_HEAD is set to point to the most recent HEAD when using reset. See "man git-reset" > EXAMPLES > "Undo a commit and redo".
- peteradio 4y ago
  git checkout prior_commit_hash "file_path"
  - WillDaSilva 4y ago
    Likely followed by git commit --amend
- eurasiantiger 4y ago
  > undo a commit git reset --hard HEAD^ Which makes perfect sense once you know that you are not ”undoing a commit” inasmuch as you are resetting the most recent state of an index to the second most previous one. Just make an alias for it if it bothers you, that’s what is generally recommended by unix beards for hard to remember but oft-used commands anyway.
  - pxmpxm 4y ago
    >once you know that you are not Making my point for me - the usage is "undo a commit" or "undo a file accidentally added to a commit", what you mentioned are implementation details that are leaking up to the interface. If I'm doing cp file newFile, I don't need to know anything about ext3, APFS or anything about hard drives to operate on files.
    - Brian_K_White 4y ago
      Isn't "undo" too ambiguous to be useful? Or do you imagine it as a subcommand with further parameters to describe what to undo and how? I think a term like undo is a mistake if you think of the git history like accounting. There is, or there should be, no such thing as undo the way an unsophisticated layperson imagines they want. Instead undos are just changes like any other changes. You don't fix entry errors by actually editing history, you make a new entry that both reverses the error and explains why. If that leads to having to think about some problems a bit non-intuitively, I'm pretty tempted to just say tough shit, it's worse to try to simplify something if simpler really only means wrong and incomplete. Perhaps undo was just a bad example of a git failing. There certainly are commands that could be more scrutable without becoming incomplete or wrong. But I only see it as an unavoidable process of development. It's not possible for anything to spring forth fully baked, and so it's pointless and wrong to complain that it didn't happen. So the crappiness of the early versions (of whatever, in general, not git in particular) is not damning and nothing else can ever be any different. Then the next, almost as unavoidable, at least certainly natural and typical, is that the process of imporoving necessarily means changing, and that leads to both redundancy and inconsistency. 4 different ways to do something because there is the old way and the next way and the next way... I see only that git could improve some things in only the way is unavoidable and applies to everything everywhere, and is not a special git failing but simply life, and that most of the perceived complexity of git comes straight from the underlying job we need it to do. It may not be logically possible to have a fundamentally simple tool to do this complex job, only a simple tool that only actually does a simple job, which isn't good enough. The best I even consider to wish for is just improvement over time figuring out more consistent interfaces and improving the predictability so that you can be more confident in understanding "when I say X, what will actially happen?".
- throw_nbvc1234 4y ago
  git reflog --help Probably not what you want to use day to day but if you want to undo things i find reflogs better then commits for tricky situations.
- phone_book 4y ago
  I love how this got 4 different answers.
  - pxmpxm 4y ago
    The question was intentionally crafted for that effect :)
  - peteradio 4y ago
    2 answers the same and rolling back all files. 1 answer for rolling back single file. 1 non-solution. The OP has a poorly defined use case for "undo" (which commit? all files or one?) and can easily wrap whichever suits their need in an alias.
UncleMeat 4y ago
Git was designed for a fully distributed open source environment where there is no canonical head and no continuous access to a source repository. It makes sense for the way that linux is developed. It makes less sense for the way that most corporate development is done. Yes, SVN is worse. That doesn't mean that git has flaws in its most common deployment.