Question

I did an evil thing in github: used rebase, then push –force. This was because I wanted to change the name associated with my commits, and have it reflected in the repository.

As is warned elsewhere, this can have consequences for other upstream or downstream repos.

The consequence I am seeing is duplicate commit messages in the upstream repo after they did a merge.

We have the following structure:

Main (fairly inactive)
– Evil (very active)
– Others (very inactive)

My question is: how do I get Main into a good state if is already has a few commits. My suggested plan of action is:

• git clone Main
• git reset [pre-merge-commit]
• git stash
• git push –force
• git stash pop
• git push

I am a little reluctant to do this without being sure it will (a) fix the problem and (b) not create more disasters. The ‘Evil’ respository has been very active since it performed its own reset/push, and I assume that they will need to do something like:

• git pull
• git reset [largest-commit-that-still-exists-on-Main]
• git stash
• git push –force (to revert ‘Evil’ to a state that exists in Main)
• (pull stuff from Main and merge normally)
• git stash pop
• git push (to apply local changes)

Is this right?

Finally, the ‘Evil’ repository has numerous commits done after it did the reset/push. Is there any way to ensure all the commit messages are preserved when it resyncs with Main?

Answer 1

Judging from what you’ve described, I’d say probably your best bet would be the second possibility mentioned in your comment – namely, continue to modify “Evil” until it is as accurate as possible, then have “Main” reset to where Evil is. Any downstream users can rebase (using the --onto flag) onto the “new world order” from “Evil”.