``` # Construct the matching branch name git branch mistake 9b888fc # Push the name alone to the remote git push -u origin mistake # Move the name of master git checkout master && git reset --hard <correct-master-sha> # Push the new name of master git push --force ```
Git reset --hard will move the name of the current working branch to another branch SHA, which is why you need to first check out the branch being moved: Its context sensitive. You are re-writing history, though. It shouldn't construct any new SHA's, but the impact on a downstream user's workflow is rough. Once it got published to public git the least impactful way forward would be to construct the inverse of the mistake and push that as its own commit instead of orphaning it. `git revert` does this in git-land. If I'm maintaining some patches against your master, then my normal workflow might be to rebase them against the current master every once in a while, with just `git rebase master`. If I did that once to rebase against the SHA which was is currently named `master`, and then invoke `git rebase master` again after your change to history, then the second rebase will also attempt to rebase your mistake onto the corrected master. User's would need to perform a one-time `git rebase --onto master mistake <my-custom-branch-name>` instead. -- Jonathan Brandmeyer _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
