@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
