On our on-prem Bitbucket instance, I can "merge" a feature branch into our main by squashing all changes of the feature branch (via Git rebase). When doing so, the commit message contains the Git commit IDs/hashes of all the squashed commits. This commit is attached to the main branch and the feature branch will be deleted.

I had suspected that the old commits would be deleted as well when deleting the feature branch, but that does not seem to be the case. Since the commit message on the main branch contains the commit IDs of all squashed commits, I am able to access each and every old commit in Bitbucket via URL. However, since the commit does not belong to a branch anymore, I cannot find the commit from the UI - neither within Bitbucket nor from any other Git client UI.

So the now squashed commits from the feature branch are only "hidden", but they still do exist within the Git repo.

Now my (rather acedemic) questions:

1. Is this always the case? Does Git always keep the squashed commits, even if the formerly associated branch has been deleted?
2. Is there any way that I can extract the commit IDs of formerly squashed commits, even if the "old" commit IDs wouldn't be part of the squashed commit message?
3. Would it be possible to "hard delete" the old commits?

Thanks in advance!

CodePudding user response：

1. Is this always the case? Does Git always keep the squashed commits, even if the formerly associated branch has been deleted?

No. Git may or may not hang on to the original commits for some time, or even forever, but there are no hard and fast rules on this, save for the usual: if a commit is reachable (via some name such as a branch or tag name), it must be retained.

(GitHub have a simple rule of their own: no commit is ever deleted. This handles some issues you can get with the fork model they use. Bitbucket may or may not have added the same rule themselves. This rule has certain drawbacks, which may lead these hosting sites to implement fancier rules down the line, allowing unreferenced commits to be deleted after all.)

2. Is there any way that I can extract the commit IDs of formerly squashed commits, even if the "old" commit IDs wouldn't be part of the squashed commit message?

No.

3. Would it be possible to "hard delete" the old commits?

Only if you have direct control over the repository. In this case you can use certain maintenance commands (git gc, git prune, and the like).

You can also clone a repository, then delete the original (and if you have the right access / permissions, install the new clone in place of the original, making the whole operation invisible to "outsiders" except for however long the downtime is to do all this). Cloning normally doesn't copy any unreferenced ("invisible except by hash ID", nominally-deleted) commits, so this gives you an easy way to clean up after mistakes. But this usually implies using a mirror clone and having direct login access to whatever site is hosting the repository.