@quartata just serially, there is a race condition if you pull then push "in the blind" because if somebody else pushed between your pull and your push, those commits will be gone
and as a result I don't believe your code functions as you think it does. Unless you can show me absolute proof that it works as is, and show me that it's been shown to work in a forked repository.
and consider i'm in a pissed off mood having to have paid the FCC coordinators another $200 just to get the freaking radio application done, so I'm really not in the best mood right now.
we still don't have a good idea of how concurrent commits to local might trample each other. The tread lock I put in should prevent that but I still don't have any good way to write a test case for that
@quartata what happens if you create a new branch with the original master, add in a commit that doesn't include the second newer upstream commit at the remote, in the new branch edit things, and try to merge
will it conflict?
what's git say? If it does conflict, then it's also a failure case
because it can't merge reliably code privs or not.
@quartata you'll note that there's now global pushback here because you don't handle any conflicts properly.
this is why we reset to upstream HEAD with Master before trying to create the new blacklist.
because we will have merge issues.
we only get merge issues currently if we have two blacklist requests which result in conflicts, or one gets merged in before the other by metasmoke and in turn is a race condition we can't solve regardless.
I'm all for rewriting this but I'm afraid we will probably need to refactor the current functionality to something we can actually test before we do anything else
there are probably failure modes we could shake out pretty quickly if we could run a test suite locally without having a mess pushed to the production master
we haven't even begun to talk about recovering in the event that somebody else pushes to master while you think you have the latest revision, Git obviously prevents you from pushing but then what?
the current implementation basically just goes into limbo, you can't do any git operations until it is sorted out locally
We could set merge=onion inside the git attributed for the blacklist/watch files, this changes the ways how git resolve the merge conflicts, and in turn can auto solve most of the conflicts we get with multiple insertion that happens when there are conflicting pull requests
@ThomasWard Back for just a second, so I just wanted to say that I think this got blown way out of proportion. This was never intended to fix everything with Git (nor could it). It was supposed to fix one very particular problem: when there are local changes, blacklist fails when trying to merge and it's not blacklisted locally or remotely. All this does is add the entry right onto the latest remote blacklist, so even if it can't merge into local master it'll still be there on the remote
What tools are available to moderators?
Moderators are our human exception handlers and will get involved when users and room owners can’t handle a situation on their own. If flags are raised or they are notified of something, then a moderator will step in to investigate and resolve the problem...
because we could have that happen. Hence why we need to work within the existing workflow and iron out bugs and problem cases before we just refactor it
I'm still scared of going live with this simply because it changes the model to one we are not yet familiar with. If only there was a way to test it without messing up production...