I noticed that after doing some git actions some commits are lost, as expected, but are still visible on github with the error: This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

To reproduce what I did:

1. repository is now: A -> B -> C
2. soft reset to commit A
3. redo commits B and C as B(mod) and C(mod)
4. repository is now: A -> B(mod) -> C(mod)
5. force push to github
6. now commit B and C can't be seen in rep history but are visible on github with above specified error

(example link where I can see it: https://github.com/user/rep/commit/B ;
while https://github.com/user/rep/commit/B(mod) appears with the expected modification)

• what could be causing this?
• does the rep contains the commits B and C or not? if yes, how can I delete them/clean the rep?

thanks

CodePudding user response：

A branch or a tag is a name that applies to a single commit. That commit is a named commit. What keeps a commit alive is that it is the parent, or the parent of the parent, or... [and so on] of a named commit.

Okay. Resetting your branch back to A means that the branch name applies now to A, not to B or to C. So there is nothing keeping B or C alive any more.

But they are not immediately destroyed either. The policy is that such commits remain until they are garbage collected. If you used the reflog you would find that they still exist on your local machine as well. It's rather like how on your computer you don't just delete a file; you put the file in the trash, and you empty the trash later. Well, Git empties its trash eventually.

You can delete them from your machine by forcing a garbage collection now. But you can't do that at GitHub; it doesn't belong to you. If you just wait, they will be destroyed on GitHub eventually.

If the matter is urgent to you, then fetch to your local repository and delete the GitHub repository altogether. Make new GitHub repository and mirror your local up to it.