5 ms·

“ - To commit you `commit`, to undo a commit you `reset --hard HEAD^` The last example is also where you get pointed to an unsafe command” Who pointed you the

“ - To commit you `commit`, to undo a commit you `reset --hard HEAD^` The last example is also where you get pointed to an unsafe command” Who pointed you there? If I want to undo my last commit, meaning the commit itself, not the changes to my file tree, shouldn’t I say `reset --soft`?

rich_sasha 5y ago
My bad, misgoogled. But this in fact reinforces my overall point. I don't want to be messing with `reset`, hard or soft. What is `reset`? [I now know because I had to learn, but I'd really rather not]. What I want is `uncommit`, or something like that.
- theli0nheart 5y ago
  git revert is probably what you want?
  - leephillips 5y ago
    This creates a new commit that reverses the changes of a past commit. That’s different from undoing your last commit, as in, you made a commit but then changed your mind, and want, say to make some more changes before you commit. (Explained in man git-revert.)
    - theli0nheart 5y ago
      That's by design; Git history is intended to be immutable when working with others. But, if you haven't pushed something up to a remote, the right command to make more changes is to use `git commit --amend`.
      - rich_sasha 5y ago
        > Git history is intended to be immutable when working with others. That's another pet peeve (though maybe less git's fault): immutable, yes, but then rebase is pushed quite liberally. Arguably not by git itself, but by many online learning resources. It's convenient, and mostly works, but then occasionally really stings you. ...yet undoing the last commit, arguably the least aggressive of history-rewriting commands, remains awkward.
        b3morales 5y ago
        Rebasing has a simple rule: it is perfectly fine as long as you haven't shared those commits.* Perhaps git should have a "checked rebase" command that requires a `--force` flag if there's an upstream branch set. *And even then it's kind of okay as long as no one else has made commits on top of the rebased commits.
        PaulDavisThe1st 5y ago
        How is "git reset HEAD~" "awkward"? It's not obviously named, but as was noted above, if there was git-uncommit, it would need every option that git-reset has, and so it would just be an alias, without the final argument. "History is immutable" is generally accepted as describing the contents of commits, not their id's or relative ordering.
        sodapopcan 5y ago
        It's also very wise to make sure you disallow force pushing to master/main/production. If you force push to a topic branch, it's usually ok. If you accidentally overwrite someone's changes, it's because you are working together and you can communicate that you messed up and for them to `pull --rebase` or however you want to resolve it. Usually that is. There's always room for disaster :)
        gpderetta 5y ago
        --force-with-lease Which BTW I learned it exists when magit switched "p -f u" to use it instead of plain --force.
        sodapopcan 5y ago
        Oh right. I always neglect to do that mostly out of laziness of typing it out on the command line. It's funny, though, I maintain a branch plugin for vim (it's a fugitive extension) and I recently accepted a PR to switch `--force` to `--force-with-lease` yet I still don't do it. I need to start doing it!
        craftinator 5y ago
    - wongarsu 5y ago
      > Explained in man git-revert If git at least had good man pages. The man-page's description is "Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them." [1] I have a hard time parsing that to mean what it's supposed to mean. It contains a note that's much better at explaining what git revert does, then goes on to explain alternatives for other things you might want to do, but doesn't mention how to undo a commit without creating a reverting commit. 1: https://git-scm.com/docs/git-revert https://git-scm.com/docs/git-revert
      - leephillips 5y ago
        “ I have a hard time parsing that to mean what it's supposed to mean.” Can’t disagree. That part could certainly be written better. I’m not saying I would want to learn Git from the man pages, but they’re pretty good in general after learning it elsewhere.
        wongarsu 5y ago
        They are decent for reference, and some are genuinely great (like git-everyday [1] or git rebase [2]). But just as often as they are helpful they just leave me scratching my head, either because they are too deep in git-lingo or because they forget to clarify some crucial details 1: https://git-scm.com/docs/giteveryday https://git-scm.com/docs/giteveryday 2: https://git-scm.com/docs/git-rebase https://git-scm.com/docs/git-rebase
      - deleted 5y ago
        [deleted]
- leephillips 5y ago
  That’s a valid point. I think there’s a near consensus, even among people who admire Git and use it constantly (like me, although I’m no expert), that the porcelain commands are confusing in some respects. On the plus side, Git’s man pages are (sometimes) useful and pretty complete. In this case, if you type `man git-commit` you’ll get a thorough rundown of all the options and it will be clear which one you should use to get what you want. EDIT: Also, since there are three arenas to keep track of, the file tree, the index, and the commit history, even if there were an `uncommit` command it would need all the flags that `reset` accepts. So it would just be `reset` renamed, which you can do yourself. But maybe some of the `reset` options should be broken out into separate commands.
- matheusmoreira 5y ago
  What is "uncommit" though? Do you want your changes gone, staged or unstaged?
  - rich_sasha 5y ago
    I’d like something like: - git revert {rev} to nuke changes and go back to how the world was - git uncommit to return to the state literally before git commit - git unstage to unstage a file The latter arguably should go with git stage but it’s a bit late for that. NB git add and git rm are totally not inverse operations... So then I can uncommit, and unstage if need be. Reverting is for discarding changes, and should come with an interactive confirmation prompt and other safety and hygiene messages.
    - matheusmoreira 5y ago
      > git uncommit to return to the state literally before git commit This is ambiguous because there are many such states. 1. Clean working tree, before you began hacking on the code. 2. Modified working tree. 3.1. Modified working tree with staged changes. 3.2. Clean working tree with staged changes. It's impossible to know which state you want to go back to without telling git. That's what hard, mixed and soft resets do: they bring you back to states 1, 2 and 3.2, respectively. The default is a mixed reset. I suppose state 2 is what most people want when they try to undo a git commit. So it already does the right thing by default, no? The only remaining problem is the git reset argument. An undo command will always reset to the previous commit, there should be no need for arguments. Stuff like HEAD^ or HEAD~1 is quite obscure to the uninitiated. We could certainly have a git undo command that runs git reset HEAD^ and allows hard and soft resets. Not sure why it doesn't already exist. Has anyone ever attempted to get that merged into mainline git?
- beermonster 5y ago
  You can always: [alias] undo = reset HEAD~1 --mixed
brundolf 5y ago
I've been using git for ~8 years and I've never heard of --soft
- leephillips 5y ago
  The default for `git reset`, which is `--mixed`, may do what you want. The difference between `--mixed` and `--soft` is that the former resets the index as well as moving the HEAD pointer; the latter only moves the HEAD, so if you’ve `git add`ed any changes, they will remain staged.
  - rich_sasha 5y ago
    Wow this is a new level of Git hell I haven’t even heard about!
    - leephillips 5y ago
      Yeah, keeping track of Git’s three areas (files, staged changes, repository) can get confusing. After some thought I think my advice to you to use `git reset --soft` would be better as just `git reset`, because that’s a neater “starting over”: it’s more of an “undo” of the last commit action, I guess. I often find myself reaching for `git reset --hard` after screwing up and not feeling like tracking down how I broke things.

rich_sasha 5y ago

My bad, misgoogled. But this in fact reinforces my overall point. I don't want to be messing with `reset`, hard or soft. What is `reset`? [I now know because I had to learn, but I'd really rather not]. What I want is `uncommit`, or something like that.

theli0nheart 5y ago
git revert is probably what you want?
- leephillips 5y ago
  This creates a new commit that reverses the changes of a past commit. That’s different from undoing your last commit, as in, you made a commit but then changed your mind, and want, say to make some more changes before you commit. (Explained in man git-revert.)
  - theli0nheart 5y ago
    That's by design; Git history is intended to be immutable when working with others. But, if you haven't pushed something up to a remote, the right command to make more changes is to use `git commit --amend`.
    - rich_sasha 5y ago
      > Git history is intended to be immutable when working with others. That's another pet peeve (though maybe less git's fault): immutable, yes, but then rebase is pushed quite liberally. Arguably not by git itself, but by many online learning resources. It's convenient, and mostly works, but then occasionally really stings you. ...yet undoing the last commit, arguably the least aggressive of history-rewriting commands, remains awkward.
      - b3morales 5y ago
        Rebasing has a simple rule: it is perfectly fine as long as you haven't shared those commits.* Perhaps git should have a "checked rebase" command that requires a `--force` flag if there's an upstream branch set. *And even then it's kind of okay as long as no one else has made commits on top of the rebased commits.
      - PaulDavisThe1st 5y ago
        How is "git reset HEAD~" "awkward"? It's not obviously named, but as was noted above, if there was git-uncommit, it would need every option that git-reset has, and so it would just be an alias, without the final argument. "History is immutable" is generally accepted as describing the contents of commits, not their id's or relative ordering.
      - sodapopcan 5y ago
        It's also very wise to make sure you disallow force pushing to master/main/production. If you force push to a topic branch, it's usually ok. If you accidentally overwrite someone's changes, it's because you are working together and you can communicate that you messed up and for them to `pull --rebase` or however you want to resolve it. Usually that is. There's always room for disaster :)
        gpderetta 5y ago
        --force-with-lease Which BTW I learned it exists when magit switched "p -f u" to use it instead of plain --force.
        sodapopcan 5y ago
        Oh right. I always neglect to do that mostly out of laziness of typing it out on the command line. It's funny, though, I maintain a branch plugin for vim (it's a fugitive extension) and I recently accepted a PR to switch `--force` to `--force-with-lease` yet I still don't do it. I need to start doing it!
        craftinator 5y ago
  - wongarsu 5y ago
    > Explained in man git-revert If git at least had good man pages. The man-page's description is "Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them." [1] I have a hard time parsing that to mean what it's supposed to mean. It contains a note that's much better at explaining what git revert does, then goes on to explain alternatives for other things you might want to do, but doesn't mention how to undo a commit without creating a reverting commit. 1: https://git-scm.com/docs/git-revert https://git-scm.com/docs/git-revert
    - leephillips 5y ago
      “ I have a hard time parsing that to mean what it's supposed to mean.” Can’t disagree. That part could certainly be written better. I’m not saying I would want to learn Git from the man pages, but they’re pretty good in general after learning it elsewhere.
      - wongarsu 5y ago
        They are decent for reference, and some are genuinely great (like git-everyday [1] or git rebase [2]). But just as often as they are helpful they just leave me scratching my head, either because they are too deep in git-lingo or because they forget to clarify some crucial details 1: https://git-scm.com/docs/giteveryday https://git-scm.com/docs/giteveryday 2: https://git-scm.com/docs/git-rebase https://git-scm.com/docs/git-rebase
    - deleted 5y ago
      [deleted]
leephillips 5y ago
That’s a valid point. I think there’s a near consensus, even among people who admire Git and use it constantly (like me, although I’m no expert), that the porcelain commands are confusing in some respects. On the plus side, Git’s man pages are (sometimes) useful and pretty complete. In this case, if you type `man git-commit` you’ll get a thorough rundown of all the options and it will be clear which one you should use to get what you want. EDIT: Also, since there are three arenas to keep track of, the file tree, the index, and the commit history, even if there were an `uncommit` command it would need all the flags that `reset` accepts. So it would just be `reset` renamed, which you can do yourself. But maybe some of the `reset` options should be broken out into separate commands.
matheusmoreira 5y ago
What is "uncommit" though? Do you want your changes gone, staged or unstaged?
- rich_sasha 5y ago
  I’d like something like: - git revert {rev} to nuke changes and go back to how the world was - git uncommit to return to the state literally before git commit - git unstage to unstage a file The latter arguably should go with git stage but it’s a bit late for that. NB git add and git rm are totally not inverse operations... So then I can uncommit, and unstage if need be. Reverting is for discarding changes, and should come with an interactive confirmation prompt and other safety and hygiene messages.
  - matheusmoreira 5y ago
    > git uncommit to return to the state literally before git commit This is ambiguous because there are many such states. 1. Clean working tree, before you began hacking on the code. 2. Modified working tree. 3.1. Modified working tree with staged changes. 3.2. Clean working tree with staged changes. It's impossible to know which state you want to go back to without telling git. That's what hard, mixed and soft resets do: they bring you back to states 1, 2 and 3.2, respectively. The default is a mixed reset. I suppose state 2 is what most people want when they try to undo a git commit. So it already does the right thing by default, no? The only remaining problem is the git reset argument. An undo command will always reset to the previous commit, there should be no need for arguments. Stuff like HEAD^ or HEAD~1 is quite obscure to the uninitiated. We could certainly have a git undo command that runs git reset HEAD^ and allows hard and soft resets. Not sure why it doesn't already exist. Has anyone ever attempted to get that merged into mainline git?
beermonster 5y ago
You can always: [alias] undo = reset HEAD~1 --mixed

brundolf 5y ago

I've been using git for ~8 years and I've never heard of --soft

leephillips 5y ago
The default for `git reset`, which is `--mixed`, may do what you want. The difference between `--mixed` and `--soft` is that the former resets the index as well as moving the HEAD pointer; the latter only moves the HEAD, so if you’ve `git add`ed any changes, they will remain staged.
- rich_sasha 5y ago
  Wow this is a new level of Git hell I haven’t even heard about!
  - leephillips 5y ago
    Yeah, keeping track of Git’s three areas (files, staged changes, repository) can get confusing. After some thought I think my advice to you to use `git reset --soft` would be better as just `git reset`, because that’s a neater “starting over”: it’s more of an “undo” of the last commit action, I guess. I often find myself reaching for `git reset --hard` after screwing up and not feeling like tracking down how I broke things.