Search code examples
gitgerrit

Few commits are missing after using -f push in gerrit


I have deleted the larger file accidentally pushed into one of our gerrit project using below commands.

1. Clone the project
2. git filter-branch --force --index-filter \
  'git rm --cached --ignore-unmatch path/to/heavy.file' \
  --prune-empty --tag-name-filter cat -- --all
3) git push origin --force --all

Now some of the commits are missing/gone from our remote project master branch. So now how do i revert the commit that i pushed forcefully (Or) how do i restore the missing commits?

git log doesn't shows the commit that i pushed. Please help me on this issue. Thanks in advance.


Solution

  • From the comments, we know that the reason this happened is because 22 new commits appeared on master during the 4 hours of time between when you cloned, and when you force pushed back out the rewritten repo.

    To get those 22 commits back:

    1. Lock the master branch so no one else commits to it while you're fixing it. (In retrospect you could have prevented the problem by locking during your previous re-write too.)
    2. Make note of the previous tip of master before your rewrote the repo. Let's call that commit M1.
    3. Find the new tip commit ID of the previous master with those missing 22 commits. It sounds like you already found it from gerrit. Anyone who had previously fetched would have had it as well, and also the person (or thing) that created that last commit would have known it. Let's call that commit M2.
    4. On your rewritten repo, checkout master: git checkout master
    5. Now cherry pick the range of 22 commits: git cherry-pick M1..M2
    6. Now push out your re-written commits: git push

    Note you shouldn't have to force push master in the last step. If you do have to force push, that means your Lock in the first step didn't work and someone added new commits again. You could reset your local master to the new tip, and repeat these steps, or fetch and then git rebase origin/master which should rewrite your 22 commits on top of the newest master again. Finally, you can git push again without force and you'll know you're fully up to date.

    Tip: Anytime you plan to force push a shared branch, best practice is to notify your team and then lock the branch so no one can commit to it.