3 ms·

I completely agree that reverting a merge in git is painful (painful, that is, in figuring out the parameters to pass to git revert). Let's say this is your sc

I completely agree that reverting a merge in git is painful (painful, that is, in figuring out the parameters to pass to git revert). Let's say this is your scenario: d Merge branch 'test' |\ | c-test Test Branch Commit 1 b | Master Commit 2 \| a Master Commit 1 And let's say you want to revert d, the merge commit. You would do this: git revert -m 1 HEAD Now your history looks like this: e-master Revert "Merge branch 'test'" | d Merge branch 'test' |\ | c-test Test Branch Commit 1 b | Master Commit 2 \| a Master Commit 1 -m, or --mainline is the key here. Git needs to know which parent is the appropriate one to revert to. As the d-b-a line is the leftmost one, its parent number is 1. Let's say that, instead, for some reason you actually wanted to rely on the d-c-a line as the basis for the commit, effectively throwing away the changes presented in commit b. You would do: git revert -m 2 HEAD That said, you almost always want -m 1. And that said, this is how I understand merge reverts to work, but I've only had to do this a few times, so take that with a grain of salt. -- With all that said, I completely agree with you about the frustration in trying to figure it out, even with SO. This is exactly where some nice porcelain sitting on top of git could make things much simpler.

jheriko 13y ago
I appreciate the effort you have made in trying to educate me here. I have recreated the problem I originally had and documented precisely why it really is a usability problem. Now that I have done this I am pretty sure that my anti-git sentiment is warranted - even if my initial comment was massively too harsh. http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html
- rallison 13y ago
  Ah, and this is why I shun fast forward merges. You were using fast forward merges (and, honestly, I absolutely cannot blame you for doing so). A very, very simple graphic explaining the difference can be seen here: http://stackoverflow.com/a/2850413/1397661 http://stackoverflow.com/a/2850413/1397661 The fast forward merge loses any concept of where the branch was branched from and when it was merged back in. Many in the community find the fast forward version cleaner. Sure, it is cleaner, until you need to revert that merge. After using git professionally for quite a while, my opinion is that one should almost always use --no-ff for merging (unless one really knows better). Sure, the history is a bit more complicated to view. But, if you want to easily revert that one merge, everything becomes much, much simpler. It adds a little complexity for the common case while significantly reducing the complexity for a number of slightly less common cases. That said, this ties back into the learning curve of git. How were you to know that you should do non-fast-forward merges so as to make merge reverts easier? Git has probably the steepest learning curve of any current version control system. It takes time to figure out the proper workflow for a company, and I've seen many rather intelligent people fail at git. By the way, you brought up valid points and questions, and I enjoyed this discussion.

jheriko 13y ago

I appreciate the effort you have made in trying to educate me here. I have recreated the problem I originally had and documented precisely why it really is a usability problem. Now that I have done this I am pretty sure that my anti-git sentiment is warranted - even if my initial comment was massively too harsh. http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

rallison 13y ago
Ah, and this is why I shun fast forward merges. You were using fast forward merges (and, honestly, I absolutely cannot blame you for doing so). A very, very simple graphic explaining the difference can be seen here: http://stackoverflow.com/a/2850413/1397661 http://stackoverflow.com/a/2850413/1397661 The fast forward merge loses any concept of where the branch was branched from and when it was merged back in. Many in the community find the fast forward version cleaner. Sure, it is cleaner, until you need to revert that merge. After using git professionally for quite a while, my opinion is that one should almost always use --no-ff for merging (unless one really knows better). Sure, the history is a bit more complicated to view. But, if you want to easily revert that one merge, everything becomes much, much simpler. It adds a little complexity for the common case while significantly reducing the complexity for a number of slightly less common cases. That said, this ties back into the learning curve of git. How were you to know that you should do non-fast-forward merges so as to make merge reverts easier? Git has probably the steepest learning curve of any current version control system. It takes time to figure out the proper workflow for a company, and I've seen many rather intelligent people fail at git. By the way, you brought up valid points and questions, and I enjoyed this discussion.