3 ms·

This only briefly touches on revert commits, and instead shows a lot of (in my opinion) dangerous history-destroying commands. Why aren't reverts more widely u

This only briefly touches on revert commits, and instead shows a lot of (in my opinion) dangerous history-destroying commands. Why aren't reverts more widely used? It seems a lot of devs I've worked with don't understand them, and to me they seem so simple and are so much safer than destroying/rewriting history.

glormph 8y ago
TIL there are revert commits, which prompted me to actually read the article and not just the HN comments. Thank you!
- Klathmon 8y ago
  It's one of my favorite things in git! Don't "pretend the commit didn't happen", actually "undo" the commit (as in commit the reverse of your change). Not only does it preserve the change in an easy-to-see manner, but you can also provide more context on why you undid your commit (my revert messages often read like "Revert "previous commit message here" due to it potentially causing some older android devices to break. More info at ticket #1234") Now not only do you have a clear history of what happened (someone added X, then you undid X at a later date), but you also have context for why the change was undone, and can either revert the revert if you need to, or just re-do the work in a new commit later. It's a great "oh shit" button that I'm much more willing to use since I know I won't have to worry about "rescuing" the commit later. If something goes wrong and I have a hunch it was caused in a commit, i'll often just revert it and investigate later when I have time.
  - ascagnel_ 8y ago
    That, and since you're preserving commit history, you can later re-enable that change by making a second revert commit of the first revert.
tome 8y ago
They don't destroy history, they just move the branch to something that's not a descendant of what it once was. You can get the history back if you want. See "All the things your branch has ever been" http://h2.jaguarpaw.co.uk/posts/git-survival-guide/ http://h2.jaguarpaw.co.uk/posts/git-survival-guide/
- Klathmon 8y ago
  Reflog is analogous to the recycle bin (when used like this). It's nice in a pinch, but I don't want to rely on it, and it doesn't keep information forever. a revert keeps that history forever in your repo (unless you do something to explicitly delete it), which IMO is just as important as all other commits.
tylersmith 8y ago
It's great to be able to go get the original commit when the time comes to try the (possibly modified) change again.
t0mbstone 8y ago
I will explain a common problem with revert commits: 1. Developer writes some code in a branch. 2. Developer merges code into master before the code was actually ready to be deployed. 3. Developer reverts the merge commit in master to roll back everything. 4. Developer fixes the code in their branch. 5. Developer merges their code into master. 6. Their code doesn't show up in master, since it was already merged in and the revert is part of the official history of the branch in master. 7. Developer has to make a revert of the revert and then untangle the mess.
- Klathmon 8y ago
  I can understand that, but I still would prefer that over the alternative of changing history, losing context at why the revert happened (or that it happened at all!), and having to dig through reflog and hope that the machine that it was done on is available and hasn't dumped the code to be able to recover the commit needed. In your scenario, it's a puzzle to unfuck, but it's unfuckable after a bit of work. In the alternative you run the risk of losing work, or blowing out other's commits and causing work for multiple other team members. I guess my point was that I feel "revert commits" should be treated as the default, and the goto in most situations, and only using something like `git reset HEAD^ --hard` when you really need to, or a revert won't do. I'll be honest, I sometimes use a "reset and force push" when I've fucked up an ugly merge, or I want to undo the last few commits at once, but it's the exception, not the first tool I reach for.

glormph 8y ago

TIL there are revert commits, which prompted me to actually read the article and not just the HN comments. Thank you!

Klathmon 8y ago
It's one of my favorite things in git! Don't "pretend the commit didn't happen", actually "undo" the commit (as in commit the reverse of your change). Not only does it preserve the change in an easy-to-see manner, but you can also provide more context on why you undid your commit (my revert messages often read like "Revert "previous commit message here" due to it potentially causing some older android devices to break. More info at ticket #1234") Now not only do you have a clear history of what happened (someone added X, then you undid X at a later date), but you also have context for why the change was undone, and can either revert the revert if you need to, or just re-do the work in a new commit later. It's a great "oh shit" button that I'm much more willing to use since I know I won't have to worry about "rescuing" the commit later. If something goes wrong and I have a hunch it was caused in a commit, i'll often just revert it and investigate later when I have time.
- ascagnel_ 8y ago
  That, and since you're preserving commit history, you can later re-enable that change by making a second revert commit of the first revert.

tome 8y ago

They don't destroy history, they just move the branch to something that's not a descendant of what it once was. You can get the history back if you want. See "All the things your branch has ever been" http://h2.jaguarpaw.co.uk/posts/git-survival-guide/ http://h2.jaguarpaw.co.uk/posts/git-survival-guide/

Klathmon 8y ago
Reflog is analogous to the recycle bin (when used like this). It's nice in a pinch, but I don't want to rely on it, and it doesn't keep information forever. a revert keeps that history forever in your repo (unless you do something to explicitly delete it), which IMO is just as important as all other commits.

tylersmith 8y ago

It's great to be able to go get the original commit when the time comes to try the (possibly modified) change again.

t0mbstone 8y ago

I will explain a common problem with revert commits: 1. Developer writes some code in a branch. 2. Developer merges code into master before the code was actually ready to be deployed. 3. Developer reverts the merge commit in master to roll back everything. 4. Developer fixes the code in their branch. 5. Developer merges their code into master. 6. Their code doesn't show up in master, since it was already merged in and the revert is part of the official history of the branch in master. 7. Developer has to make a revert of the revert and then untangle the mess.

Klathmon 8y ago
I can understand that, but I still would prefer that over the alternative of changing history, losing context at why the revert happened (or that it happened at all!), and having to dig through reflog and hope that the machine that it was done on is available and hasn't dumped the code to be able to recover the commit needed. In your scenario, it's a puzzle to unfuck, but it's unfuckable after a bit of work. In the alternative you run the risk of losing work, or blowing out other's commits and causing work for multiple other team members. I guess my point was that I feel "revert commits" should be treated as the default, and the goto in most situations, and only using something like `git reset HEAD^ --hard` when you really need to, or a revert won't do. I'll be honest, I sometimes use a "reset and force push" when I've fucked up an ugly merge, or I want to undo the last few commits at once, but it's the exception, not the first tool I reach for.