3

recently I cleaned up my git repo by using git rebase -i --root master. I squashed a few commits together, edited some, set the time accordingly and at the end I used git push --force-with-lease origin master to push my local state to remote.

This worked just fine and my repo is now cleaned up as seen here, but somehow I was able to find an old commit hash and when searching for it explicitly via the url, I am still able to view the old tree that is not used anymore as seen here.

So my question is if and how it is possible to delete these old commits/trees from my remote repository?

Any ideas?

phd
  • 82,685
  • 13
  • 120
  • 165

4 Answers4

1

You may wanna check this answer.

TL;DR :

They will be removed after a while if they don't belong in a branch or a tag.

Martin Verjans
  • 4,675
  • 1
  • 21
  • 48
1

If you want to remove them manually, you can use pick and drop command.

pick commithash
drop commithash

For example:
git rebase -i --root master
pick 2d224bc6cec9b33ae9b910dbef5efdd707625383
drop 2d224bc6cec9b33ae9b910dbef5efdd707625383

1

"Removing" a commit does not actually remove it: it sticks around for a while. You just can't find it any more unless you have saved the hash ID somewhere.

You saved the hash ID, 3597386eaa550367e5531e4ec019f04e1d7e40df. More precisely, the GitHub URL you saved includes the hash ID, which you then present to GitHub, so that they can use the hash ID on their side—and that still locates the commit, which is still there.

It will continue to be there until it isn't. Exactly when that will be is hard to say: Git has a maintenance command that cleans up unused commits. In your own copy of the repository, you can run this maintenance command on your own schedule. In the copy over on GitHub, you're at the mercy of their maintenance schedule.

(If it's really important, you can ask the GitHub folks to do an early cleaning. However, most things that you could handle this way—such as getting rid of a commit that exposed a password—are well into the "too late" period by the time you can actually get it done, so there's rarely any reason to bother with this.)

torek
  • 448,244
  • 59
  • 642
  • 775
1

The accepted answer is great.

What I want to add though, is that GitLab allows you to tune how frequently the cleanup jobs (git gc and git repack) are executed on the remote repository, see the documentation for details.

wtj
  • 439
  • 4
  • 5