GitHub Source view shows commit that does no longer exist

Question

I rewrote the history of a GitHub repository two weeks ago (rebase and some cherry-picks) and force pushed it back to GitHub via

git push -f origin master

Everything went fine, at least it looked that way and git log showed the correct commit history. I know, rewriting history is bad practice, but the repository is new and I'm the only user, so there should not be any troubles for others.

My repository has only one branch, named master.

Now to my problem. GitHub's Source view of my repository shows at least one commit that should no longer exist due to my rewriting of history. And indeed it does not exist in my local nor in GitHub's commit log (but it is part of my local reflog). How do I get rid of this commit and possibly others that are in my remote GitHub repository? Is there any way to clean up a remote repository and delete those "unreachable" commits that are not part of the commit log?

BTW if I clone the GitHub repository, the rogue commit is not present in the clone. git show <SHA1> returns fatal: bad object.

My question is very similar to SO 4367977 but the solution to that question "waiting for GitHub's garbage collection" did obviously not work. The commits-links still work after 6 months have passed.

Deleting the repository and recreating it should solve the problem but this it not very elegant.

Thanks in advance!

This sounds more like a question for Github Support than Stack Overflow... not much we can do about this from the outside, it looks like a clear flaw in their system =/ — Adrian Petrescu, Jun 24 '11 at 18:28
Is there any way I can force push my local repository again? `git push -f origin master` naturally says I'm already up-to-date. — Benjamin, Jun 24 '11 at 18:43
Returns already up-to-date. What is the difference between `git push -f origin master` and `git push origin +master`. Is there any? — Benjamin, Jun 24 '11 at 19:01
possible duplicate of [How to remove a dangling commit from GitHub?](http://stackoverflow.com/questions/4367977/how-to-remove-a-dangling-commit-from-github) — Ciro Santilli OurBigBook.com, Sep 29 '15 at 09:25

Paŭlo Ebermann · Accepted Answer · 2011-06-24T21:19:31.407

0

Commits do not silently disappear from a repository due to rewriting history, they just get not referenced any more.

Pushing to a repository means uploading a list of objects and then setting some tags and or branches to some commit. It does not mean remove any commits (and other objects) from the target repository that are not used by the branches as now.

As you checked by cloning, the commit is not reachable anymore. In theory, it should be garbage collected eventually, but as you observed, this may not happen soon - maybe never. (Could it be that someone forked from the commit mentioned in the other question you linked, and this hinders garbage collection?)

If there is any confidential data in the "wrong" commit, contact the github support to remove it. If not, simply ignore the commit - it does no harm sitting there in the repository.

edited Jun 24 '11 at 21:19

answered Jun 24 '11 at 20:16

Paŭlo Ebermann

73,284
20
146
210

1

I've rewritten history a couple of times on my Github repo's and the commits are still there in the web interface, but are no longer reachable from anywhere. I agree, just let them be unless they contain something of importance. – X-Istence Jun 24 '11 at 20:20
Thanks for the explanation. I'm not sure if the repository from the liked SO question had been forked or not. I was under the impression that forcing a push would delete everything unneeded in the remote repository. But this is not the case. Another reason for the commits not being garbage collected might be GitHub's news feed logging all your actions/commits. – Benjamin Jun 30 '11 at 16:32

GitHub Source view shows commit that does no longer exist

1 Answers1

Linked