2 ms·

'- Revert the merge commit' this is what i had problems with. i got an error message back from git that you can't revert a branch commit and when i googled it t

by jheriko 13y ago

'- Revert the merge commit' this is what i had problems with. i got an error message back from git that you can't revert a branch commit and when i googled it the conclusion i came to was i needed to go back in time and change our configuration to make this possible. its entirely possible that i ended up down the wrong path from google searching. now, googling around i find some stack overflow answers and such i'm pretty sure i found at the time i had the issue. when i am next there (at work) i'll see if i can find a copy of that repo or recreate the same problem so that i can show what happened and why it is difficult to solve and dangerous in a production environment. actually... i might just try and repro it now, but my connection is so poor here (at home) that even installing git is likely to be painful. however, ignoring that, the process you describe is horribly counter intuitive. well done for working it out in the first place, although i do see this suggested in a few of the stack overflow answers... :)

stormbrew 13y ago
It's possible that when you were doing this things were different, because even in the last year or so it seems like git has become a lot less esoteric in its interface, but the man page for git revert currently explains a fair bit about how to use it to revert a merge commit. Basically you just need to specify which parent (of the merge commit's 2 parents) is the one that should survive the reversion with '--mainline'. This seems intuitive to me, with a maybe deeper than average understanding of git, though the rather more involved process of undoing the reversion is less so.
- jheriko 13y ago
  yeah, i feel like this is almost certainly the case. that man page was absolutely my first stop when i got the error message and looking at it now i can't imagine how distracted and stupid i must have been to have missed all of that information. its a weak argument, but i have never struggled to learn anything when provided sufficient information. usually much less than that is enough...
rallison 13y ago
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.

by jheriko 13y ago

stormbrew 13y ago

It's possible that when you were doing this things were different, because even in the last year or so it seems like git has become a lot less esoteric in its interface, but the man page for git revert currently explains a fair bit about how to use it to revert a merge commit. Basically you just need to specify which parent (of the merge commit's 2 parents) is the one that should survive the reversion with '--mainline'. This seems intuitive to me, with a maybe deeper than average understanding of git, though the rather more involved process of undoing the reversion is less so.

jheriko 13y ago
yeah, i feel like this is almost certainly the case. that man page was absolutely my first stop when i got the error message and looking at it now i can't imagine how distracted and stupid i must have been to have missed all of that information. its a weak argument, but i have never struggled to learn anything when provided sufficient information. usually much less than that is enough...

rallison 13y ago

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.