How to delete a specific revision of a github gist?

Question

I created a Gist on GitHub and I saw informations I don't want anyone to see. I updated the file since, but everybody can still access the old revision of the file.

Except deleting the Gist, is there a way to delete that particular revision definitely?

I saw that I'm not the only one having that kind of problem (Git: delete a single remote revision) but I didn't manage to remove the revision. The process indicated here seems to help remove some files. I want to remove the whole revision.

Answer 1

Github has a help page about removing sensitive data:

http://help.github.com/removing-sensitive-data/

As gists are just git repositories, you should be able to locally clone your gist, do the clean-up there and do a forced push to overwrite the github version with the cleaned repo.

Yes, after thinking about it: If <commit> is the commit you want to "remove", do

 git rebase -i <commit>^

mark the line for <commit> as edit, save and quit.

git will set up the working directory to the state after you comitted <commit>. Fix the file, use git add and git commit --amend to fix the commit. Then do git rebase --continue. If the only thing, the next commit did, was to remove the sensitive data, it will probably be automatically dropped because it doesn't contain any changes after the now-amended commit.

Then, do a git push -f to force the update (because it is now non-fast-forward, meaning it changes already published git history).

Answer 2

The accepted answer is good but a bit difficult to follow. Here's the same answer but a bit sweeter.

As Tilman Vogel says, gists are just repositories and so this approach works for github repositories as well as gists.

Let's assume that there is just one version that contains a password that you don't want to show. You've checked in the new version with the password removed and want to get rid of the previous version. You should be able to adapt this process if there are a number of commits showing the password.

The first thing is that the repair has to be done on your local machine (not in github). To do this start by cloning the gist locally. The gist's page on github should show you how to create a private clone if you click on the private clone URL. Something like:

git clone [email protected]:421xxx1.git gist-421xxx1

This gives you a local copy that you need to rebase (meaning muck around with the versions).

cd gist-421xxx1
git rebase -i eexxaa^

Where eeccaa is the (first) version containing the password. You can get this number from the gist page revisions column. The ^ is required. The command means 'let me change the verisons from eexxaa to the latest, interactively. The command opens up an editor populated with a command on each line for each version in the repo. The default command is 'pick' meaning 'use or keep this version'.

The first lines in the editor should look something like

pick eexxaa    <- the version with the password
pick ffxxbb    <- the first version without the password

Change this to

pick eexxaa    
squash ffxxbb 

I.e. Change the word 'pick' to 'squash' on the version without the password. This will ask the rebase to squash the new (passwordless) version into the old (password carrying) one, essentially deleting version eexxaa. Obviously your versions will be other than eexxaa or ffxxbb don't literally use eexxaa or ffxxbb anywhere!

As @kand notes, you should squash every version that contained the password.

In the editor save and quit (if it's vi :x). The rebase should now open a new editor showing the commit messages for the two versions and asking for a single combined commit message. For a gist these messages are quite likely to be empty but you do need to put something in here or the rebase will abort. Type a message, save it and quit and the rebase should complete.

You now have a repository without the password-containing version. To get this back to the gist use:

git push -f

This will force the changes onto the github repo. Hit refresh and you should be able to check in the browser that the offending version has gone from the revisions column on the right hand side.

Thats it!

Answer 3

If you are not concerned about showing any of the revisions on the gist, you can do the following to eliminate all history and just show one revision.

git clone some-gist-repo
cd some-gist-repo
git rebase -i --root $tip

You would be able to see all the commits for that gist in your editor. Just pick the first one and replace everything else with s or squash. Once done, save and add a commit message and then do a force push to master like this and you are good.

git push -f origin master

The only revision that would be visible is the addition of file(s) and thats it.

Answer 4

If you want to completely delete something from the repository you need to use git filter-branch.

http://git-scm.com/docs/git-filter-branch

Answer 5

tested @ 2022-03

---

many solution based on squash way.

I just say delete last one (or more) commits directly
?(without squash, no new commit version generate), which may have common situation.

drop commit solution

when git rebase -i eexxaa^ step,
just mark last unwant commit as drop, save it.

finally git push -f
then the drop version also delete in gist page.

where get the repo url of gist ?

just open the gist page > copy url in broswer addressbar,
?use git clone $the_url, it works.

note: use http(s) also need github access token rather than password;
?access token only need gist permission (can do force push)

Answer 6

Adding to meesern's answer. When you try to squash or fixup and rebase--continue, you are required to add a comment or --allow-empty-message. This is time consuming, and somehow my commits did not go away from the gist's revision list by doing that way.

I found a simpler solution: You can just delete the unnecessary commit lines on your rebase to-do list, :wq!, git rebase --continue, and git push -f.

Answer 7

I tried the other answers here but had two problems:

1. I couldn't rebase it, I think it was because the repository is with commits without messages.
2. I couldn't push it (yes, with force).

I solved those two problems by first creating another branch on the first commit, and cherry-picking the rest of the commits one-by-one, without committing them automatically (so that I can edit them before commit).

After that, I reset the master branch to the new branch: git switch master && git reset --hard temp.

And before pushing, I changed the remote to the SSH version:

git remote set-url origin [email protected]:<<gist id>>.git

And then, using git push --force it pushed and changed the gist revisions.