Completely remove commit from Bitbucket history

Question

I've made a wrong commit and I pushed it to my private bitbucket.org repository. How can I completely remove this commit from the remote repository's history?

I tried the following:

git reset --hard HEAD~1
git reset HEAD~
git commit -m "some message"
git push -f

I did this based on solution from Bitbucket git reset

Yet, previous commits are accessible via Bitbucket's web interface.

I mean they are still accessible using a link like https://bitbucket.org/user/repo/commits/<deleted commit hash> (although they are not listed in repository commits in the web interface).

Is this information (the history which I intended to delete) fetched from my repository?

Or

1. Is this some feature of bitbucket.org?
2. Did I take some step(s) wrong? Which?
3. How to completely remove a commit from history on bitbucket.org?

Answer 1

1. This is a combined feature of both BitBucket and Git itself. Git commits are immutable objects. You can not move their position in the history graph, only create new commits in other locations, and sometimes delete swaths of commits.

   A branch is just a moving label (a tag is a static label, tied to a commit). When a branch is HEAD, any commits you make move the label along with them. You can move the same label to an unrelated part of the graph, not necessarily just forward and back. When you rebase, that's exactly what happens. New commits with (mostly) the same content as the originals are created at the new base, and the branch label is moved to point to them. You can always purge unreferenced commits that don't belong to a branch on your local repo.

   This is all fine when you are working locally. Once you start working with remotes, you have to start taking into account that you may not be the only one using the repo. Once you've done a force push of a rebased branch, a couple of things happen:

   1. The newly created commits are pushed to the remote
   2. The branch label on the remote of the branch you are tracking is updated to the new commits

   The commits in the old branch are no longer referenced by you or the server, but they still exist. In fact, any other users that cloned your repo will still point to these commits in their local versions until they explicitly change the history on their end. In fact, if they were to do a force push, the branch label would move right back to where it was, discarding your rebase.

   Git does not impose a hierarchy on the repos you clone. Each one is as much a representation of the true state of your code as any other. For this reason, apparently unused commits are kept around for a while, even when they don't appear in the history a local branch. That being said, git can prune such unreferenced commits periodically if they reach a certain age without getting and new descendants.

2. Given the information above, you didn't do anything wrong. The deleted commit is not going to be cloned without an explicit reference to its hash. There's a good chance that if you leave the commit alone long enough, it'll get purged automatically. If that's good enough, you can let it be. If, on the other hand, you reeeeaaaly need that commit gone, read on.

3. The most reliable way to ensure a clean repo is to start from scratch. You can create a local repo that is pruned, purged, and generally to your spec. Once you've done that, you can delete the server copy. Then, create a new empty repo with the original's name, and push your pristine history to it.