I share some blame for the existence of this thread. I spotted the git author issue after that commit was merged and was too lazy to revert and fix it. I personally tend to dislike reverting stuff way more than I should (like a prior schema change that was merged without the site being updated). I should have just reverted that immediately and left a new patch waiting for +2.
Patches by person A that just split out a class or function made by person B should still be looked at by someone other than person A. I think it's a border case, but leaning on the side of caution is the best bet. It sucks to have the code break due to something that was accidentally not copied. I don't think it's worth reverting something like that just for being self-merged (which is why didn't), but it's good practice to avoid. If a string of basic follow-ups are needed and people complain, it might be worth reverting though (like what happened here). We can always add patches back into master after giving it a second look, so reverting isn't always a huge deal and need not be stigmatizing. I need to get used to the revert button more; lesson learned. :) -- View this message in context: http://wikimedia.7.n6.nabble.com/Really-Fast-Merges-tp4990838p4990923.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
