Nope. If they're not careful (or don't know), they'll just merge in the bad commits on the next pull. They'll have to know in advance, and do some manual resetting or use a rebase call.
This is one of problems with changing history in a "master" repository. In this case, it's necessary in order to fix a problem.
Odds are since they're reverting back to an earlier commit on the master branch, anyone who does a pull might not notice the change since they're "ahead" in their history which is okay from the standpoint of the pull (using merge). This will cause a problem for any later push since they'll place the bad commits right back into the GitHub repo. [I'd like to put together a test scenario for this to be 100% but I'm not set up for that at the moment.]
Doing a rebase will lead to the "unmerging" conflicts that they had encountered and caused all their frustration.
Everyone needs to be notified to move (rename) their current master and recreate a master tracking branch:
This just solves the problem with the master branch. Any local development branch based directly off the master will need to be rebased. Or they can create a new development branch and cherry-pick.
Comments
Nope. If they're not careful (or don't know), they'll just merge in the bad commits on the next pull. They'll have to know in advance, and do some manual resetting or use a rebase call.
This is one of problems with changing history in a "master" repository. In this case, it's necessary in order to fix a problem.
Odds are since they're reverting back to an earlier commit on the master branch, anyone who does a pull might not notice the change since they're "ahead" in their history which is okay from the standpoint of the pull (using merge). This will cause a problem for any later push since they'll place the bad commits right back into the GitHub repo. [I'd like to put together a test scenario for this to be 100% but I'm not set up for that at the moment.]
Doing a rebase will lead to the "unmerging" conflicts that they had encountered and caused all their frustration.
Everyone needs to be notified to move (rename) their current master and recreate a master tracking branch:
This just solves the problem with the master branch. Any local development branch based directly off the master will need to be rebased. Or they can create a new development branch and cherry-pick.