4 ms·

Git revert has undesired side effects for merges. If you have a merge-only workflow (GitFlow, for example), and your pull request breaks something, a revert com

Git revert has undesired side effects for merges. If you have a merge-only workflow (GitFlow, for example), and your pull request breaks something, a revert commit will not help you. After a revert, all the commits that were merged, are still merged, but then they're deleted. The next time you pull, git will delete the changes in your working branch. In a merge workflow, you have to either fail forward (fix the problem, rather than backing out the merge), or reset/rebase the shared branch, and email repair instructions to everyone on the team.

lmm 9y ago
Create a feature branch, revert the revert, and then fix the problem. It sounds a little weird but it works fine.
- falsedan 9y ago
  It’s a lot of paperwork to avoid a perfectly safe and normal git command.
  - sirmarksalot 9y ago
    To be fair, rebasing a shared branch really isn't all that safe. You can potentially make life hard for a lot of people.
    - falsedan 9y ago
      That’s not fair. That’s fear, uncertainty, doubt. Those people pulling that shared branch will see a big honking warning message, which can easily be resolved if you communicate what’s happening and why you rebased the upstream. When you say, it’s not safe, it sounds like you could lose work or someone could be hurt, when it’s more likely that the removed ancestors could be merged back in by someone not using ‘git pull —rebase’, or other devs being put out by having to resolve some conflicts. It’s not great, but it’s a far cry from unsafe or DANGEROUS! MUST AVOID! PUBLIC SHAMING!
      - falcolas 9y ago
        Anytime you normalize a workflow around using unsafe commands, you risk desensitization to those very warning messages you're relying on to save you. If you have one rebase with a force push a week, people will quickly stop asking "who did the force push", since it has become normal. They'll instead just let the force push come through to their local repo, just to find out that the force push rolled the repo back a year. Now productivity is halted dead until someone goes in and fixes it and makes yet another force push. The worst part to me is that it makes the repo lossy. The entire purpose of having version control is actively subverted in the name of "clean".
        falsedan 9y ago
        I think this is fine, but then I'm comfortable with what a force-push is (a remote reset) and I know that the commits still exist even when the ref is moved, and how to inspect the history of a bare repo to move the ref back. I don't understand the business requirement for a non-lossy repo. In my experience, we need to be able to link a release to a specific commit, and we need to show that the changes were reviewed & tested before they were deployed. We use tags for this. I also think the entire purpose of source control is to be able to answer question like "who changed this? when was it changed? why?". > Now productivity is halted dead Because of a bad push to a single repo? I really like the distributed nature of git, which lets me stay productive even when other repos and branches elsewhere are having issues. I would avoid treating git as 'SVN but newer'.
  - lmm 9y ago
    No it isn't. You'd always want to create a feature branch so that you can PR the fix - it's a change going into master, it should go through the normal change-going-into-master review flow. And you'd always have to run some command to indicate that this was the branch where you wanted to undo what you'd done to master. That the command is called "revert" is a little weird, but it's no more paperwork than any other command would be.

lmm 9y ago

Create a feature branch, revert the revert, and then fix the problem. It sounds a little weird but it works fine.

falsedan 9y ago
It’s a lot of paperwork to avoid a perfectly safe and normal git command.
- sirmarksalot 9y ago
  To be fair, rebasing a shared branch really isn't all that safe. You can potentially make life hard for a lot of people.
  - falsedan 9y ago
    That’s not fair. That’s fear, uncertainty, doubt. Those people pulling that shared branch will see a big honking warning message, which can easily be resolved if you communicate what’s happening and why you rebased the upstream. When you say, it’s not safe, it sounds like you could lose work or someone could be hurt, when it’s more likely that the removed ancestors could be merged back in by someone not using ‘git pull —rebase’, or other devs being put out by having to resolve some conflicts. It’s not great, but it’s a far cry from unsafe or DANGEROUS! MUST AVOID! PUBLIC SHAMING!
    - falcolas 9y ago
      Anytime you normalize a workflow around using unsafe commands, you risk desensitization to those very warning messages you're relying on to save you. If you have one rebase with a force push a week, people will quickly stop asking "who did the force push", since it has become normal. They'll instead just let the force push come through to their local repo, just to find out that the force push rolled the repo back a year. Now productivity is halted dead until someone goes in and fixes it and makes yet another force push. The worst part to me is that it makes the repo lossy. The entire purpose of having version control is actively subverted in the name of "clean".
      - falsedan 9y ago
        I think this is fine, but then I'm comfortable with what a force-push is (a remote reset) and I know that the commits still exist even when the ref is moved, and how to inspect the history of a bare repo to move the ref back. I don't understand the business requirement for a non-lossy repo. In my experience, we need to be able to link a release to a specific commit, and we need to show that the changes were reviewed & tested before they were deployed. We use tags for this. I also think the entire purpose of source control is to be able to answer question like "who changed this? when was it changed? why?". > Now productivity is halted dead Because of a bad push to a single repo? I really like the distributed nature of git, which lets me stay productive even when other repos and branches elsewhere are having issues. I would avoid treating git as 'SVN but newer'.
- lmm 9y ago
  No it isn't. You'd always want to create a feature branch so that you can PR the fix - it's a change going into master, it should go through the normal change-going-into-master review flow. And you'd always have to run some command to indicate that this was the branch where you wanted to undo what you'd done to master. That the command is called "revert" is a little weird, but it's no more paperwork than any other command would be.