@arkodg @mavenugo I wonder if we should use this approach; if I look at d070217, then git still says it's in master (but TBH, never checked if the same applies for other ways to revert)

git branch --contains 5e34060735b93be498375093269615cbf606ecf5 
...
master

reverting the individual commits, instead of the merge commit (not sure what's better?)

I have a weak preference for reverting individual commits, but when I look into #2466 it seems like a fine approach to me as well.

git still says it's in master (but TBH, never checked if the same applies for other ways to revert)

Once committed, it will always be there, even after the revert, since it's basically a blockchain and you can't rewrite the history (unless, of course, you use git reset (and git push --force), which is something that should not ever be done unless it's your own private repo).

Once committed, it will always be there, even after the revert, since it's basically a blockchain and you can't rewrite the history (unless, of course, you use git reset (and git push --force), which is something that should not ever be done unless it's your own private repo).

Ah, yes, I realised that; wasn't sure what git branch --contains would show (hoping it would be smart to tell if it's still in the branch (as in "not reverted") guess that's not easy))