6 ms·

Git reset vs. Git revert

54 points by github-cat 8y ago

danielhlockard 8y ago
Why is this linked to the comment section?
- futureastronaut 8y ago
  Who knows, but from those comments: > Really hard to take anything you say seriously when you use the entire aplhabet for your hexadecimal SHA1 examples. Touche.
  - quickthrower2 8y ago
    I like those hashes. Why don't we use the entire alphabet. Base64 would be cool.
    - black-tea 8y ago
      Way harder to remember a hash using base64. Hex is much more manageable and you still only need to remember 4-5 digits usually.
      - quickthrower2 8y ago
        If it is about memory, why not generate 4 or so words as the 'visual' hash, which is probably good enough for most teams to use for branching/merging without experiencing clashes.
cataflam 8y ago
The explanation that made me understand git reset the best is "Git Tools – Reset Demystified" from the Pro Git book [0]. Everything has been crystal clear since. I highly recommend it if you use git. [0] https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified
amingilani 8y ago
I always use a soft reset when I accidentally commit in the wrong order, because I like keeping my history tidy. If the change is live, I always use revert. On another note, I love how HN can go from complex research papers I struggle to keep up with, to explaining git commands the next day — something I learned within my first month of Git and never had a problem with again. How bipolar.
- kazinator 8y ago
  If you commit in the wrong order and want to set it straight, learn to use "git rebase -i" (i.e. --interactive) "git reset --patch" is useful for unraveling changes that were wrongly combined into a single commit.
  - JshWright 8y ago
    Interactive rebasing works fine for teasing apart commits as well (maybe slightly clumsier, but c'mon... it's git, it's _supposed_ to be a frustrating UX)
    - bb88 8y ago
      Yes... it is, until you realize it's a command line manipulation of a data structure. Rebase, branching, diff, cherry pick, merging is just manipulating a DAG. When you're on your own branch it's often easier to think of it as a linked list.
      - black-tea 8y ago
        Even if you're on your own branch you can easily get a DAG after rebasing or resetting. The reflog keeps track of the history of all refs (ie. branch names) that you change. After you rebase your old commits are still there! It's actually quite hard to remove commits. Trusting the reflog is key to becoming good at git.
    - kazinator 8y ago
      How do you do that? I use interactive rebasing as the backdrop for teasing apart commits that are not the HEAD commit; it provides the navigation through the commits. The cherry-pick operations that underpin rebase are not what actually does the teasing-apart, though; I do that with with git reset --interactive HEAD^ when I've landed using "edit" on the commit I want to separate.
emeraldd 8y ago
The chunk about `git reset --hard` should be prefixed with a big warning label saying "Don't use this unless you know exactly what you're doing". There are very few legitimate reasons to use `git reset --hard <commit>` in the way that the article describes and even fewer if you're working with remote. Now `git reset` (No commit or --hard) can be useful to retry a screwed staging, but that's about it. As to squashing commits... that's a whole different set of problems when you're dealing with auditors and code review requirements and "public" commits.
- tomc1985 8y ago
  Very few? I find myself having to use it a lot (usually targetting HEAD or HEAD~1), and actually it's kind of handy for clearing out any cruft when switching between project branches. The important thing to know is that it only acts on files that are added to git, and will pass over any that are not.
  - emeraldd 8y ago
    I've used `reset` that way a few times, but pretty much never `reset --hard` Still, this is not something that should be suggested to someone unfamiliar with git. It's just too easy to screw up your codebase.
- dahart 8y ago
  Yeah, it’s unfortunate that the first two examples, reset --hard, and push -f, are two things you should avoid doing, especially if you’re new to git.
__david__ 8y ago
I think the main thing is, if you've already pushed to somewhere where others will pull from then use revert. Otherwise, use rebase (or reset+cherry-pick or amend, etc). If you push a patchset that has a patch and also a revert patch for that patch then you're just adding completely unnecessary noise for anyone who is reviewing the patches.
jancsika 8y ago
I love how the illustrations are actually the obvious default interface that everyone should be using to edit nodes in a graph. Click "Delete" while the box is around C and D: done. (Or right clicking and choosing "commit a reversion" or whatever.)
dabitude 8y ago
This is a pretty bad article. In the last example (which is actually the most common case in practice), they give wrong instructions. They should only revert the bad commit, not all the following commits. Reverting everything is impractical and useless, and if you want to do that you may as well use revert (which is still a bad idea).

54 points by github-cat 8y ago

danielhlockard 8y ago

Why is this linked to the comment section?

futureastronaut 8y ago
Who knows, but from those comments: > Really hard to take anything you say seriously when you use the entire aplhabet for your hexadecimal SHA1 examples. Touche.
- quickthrower2 8y ago
  I like those hashes. Why don't we use the entire alphabet. Base64 would be cool.
  - black-tea 8y ago
    Way harder to remember a hash using base64. Hex is much more manageable and you still only need to remember 4-5 digits usually.
    - quickthrower2 8y ago
      If it is about memory, why not generate 4 or so words as the 'visual' hash, which is probably good enough for most teams to use for branching/merging without experiencing clashes.

cataflam 8y ago

The explanation that made me understand git reset the best is "Git Tools – Reset Demystified" from the Pro Git book [0]. Everything has been crystal clear since. I highly recommend it if you use git. [0] https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified

amingilani 8y ago

I always use a soft reset when I accidentally commit in the wrong order, because I like keeping my history tidy. If the change is live, I always use revert. On another note, I love how HN can go from complex research papers I struggle to keep up with, to explaining git commands the next day — something I learned within my first month of Git and never had a problem with again. How bipolar.

kazinator 8y ago
If you commit in the wrong order and want to set it straight, learn to use "git rebase -i" (i.e. --interactive) "git reset --patch" is useful for unraveling changes that were wrongly combined into a single commit.
- JshWright 8y ago
  Interactive rebasing works fine for teasing apart commits as well (maybe slightly clumsier, but c'mon... it's git, it's _supposed_ to be a frustrating UX)
  - bb88 8y ago
    Yes... it is, until you realize it's a command line manipulation of a data structure. Rebase, branching, diff, cherry pick, merging is just manipulating a DAG. When you're on your own branch it's often easier to think of it as a linked list.
    - black-tea 8y ago
      Even if you're on your own branch you can easily get a DAG after rebasing or resetting. The reflog keeps track of the history of all refs (ie. branch names) that you change. After you rebase your old commits are still there! It's actually quite hard to remove commits. Trusting the reflog is key to becoming good at git.
  - kazinator 8y ago
    How do you do that? I use interactive rebasing as the backdrop for teasing apart commits that are not the HEAD commit; it provides the navigation through the commits. The cherry-pick operations that underpin rebase are not what actually does the teasing-apart, though; I do that with with git reset --interactive HEAD^ when I've landed using "edit" on the commit I want to separate.

emeraldd 8y ago

The chunk about `git reset --hard` should be prefixed with a big warning label saying "Don't use this unless you know exactly what you're doing". There are very few legitimate reasons to use `git reset --hard <commit>` in the way that the article describes and even fewer if you're working with remote. Now `git reset` (No commit or --hard) can be useful to retry a screwed staging, but that's about it. As to squashing commits... that's a whole different set of problems when you're dealing with auditors and code review requirements and "public" commits.

tomc1985 8y ago
Very few? I find myself having to use it a lot (usually targetting HEAD or HEAD~1), and actually it's kind of handy for clearing out any cruft when switching between project branches. The important thing to know is that it only acts on files that are added to git, and will pass over any that are not.
- emeraldd 8y ago
  I've used `reset` that way a few times, but pretty much never `reset --hard` Still, this is not something that should be suggested to someone unfamiliar with git. It's just too easy to screw up your codebase.
dahart 8y ago
Yeah, it’s unfortunate that the first two examples, reset --hard, and push -f, are two things you should avoid doing, especially if you’re new to git.

__david__ 8y ago

I think the main thing is, if you've already pushed to somewhere where others will pull from then use revert. Otherwise, use rebase (or reset+cherry-pick or amend, etc). If you push a patchset that has a patch and also a revert patch for that patch then you're just adding completely unnecessary noise for anyone who is reviewing the patches.

jancsika 8y ago

I love how the illustrations are actually the obvious default interface that everyone should be using to edit nodes in a graph. Click "Delete" while the box is around C and D: done. (Or right clicking and choosing "commit a reversion" or whatever.)

dabitude 8y ago

This is a pretty bad article. In the last example (which is actually the most common case in practice), they give wrong instructions. They should only revert the bad commit, not all the following commits. Reverting everything is impractical and useless, and if you want to do that you may as well use revert (which is still a bad idea).