"git reset --hard" command does not delete unnecessary commits

Question

I'm following a Udemy tutorial and so I downloaded a repository from GitHub with 50-60 commits.

Now I want to jump to a certain commit, e.g. commit 16, and delete the commits I don't need (in this case 17-50). I'm absolutely sure, that I won't need the commits I want to get rid of.

Therefore I made a reset --hard certain_hash which put the head to the right commit, however the other unneeded commits (17 - 50) are still there.

How can I get rid of the unnecessary commits?

what is 'remove commits" for you? actually, to are pointing at the right place, thus are you trying to remove commits completely from disk? — OznOg, Jun 15 '19 at 09:08
You should use `HEAD` to reset how many commits you want to reset. `git reset --hard HEAD~33`. — Alexpandiyan Chokkan, Jun 15 '19 at 09:09

VonC · Answer 1 · 2019-06-15T20:16:01.203

If those commits 17-50 are not referenced by any local or remote-tracking branches, then they will disappear.

In your case, they are likely still referenced by origin/master:

git remote remove origin is a bit extreme, especially if you need to push back later
simply force pushing (after reset) should be enough (git push --force) to update the local tracking branch and the remote one.

Type git branch -a --contain 96e6c82 to check the output is not empty.

You would need at the very least to git push --force in order for master to include only the commits you want.

score 2 · Accepted Answer · answered Jun 15 '19 at 15:24

2

I think a part of VonC's answer solves your problem " ...In your case, they are likely still referenced by origin/master..."

Just detach the reference from the remote origin by git remote rm origin Then the other commits will disappear.

answered Jun 15 '19 at 15:24

Jonathan Warner

325
5
11

score 1 · Answer 3 · answered Jun 15 '19 at 16:23

Remember that Git's normal way of working is simply to reference some standalone commits as being "top of branches or tags". These commits, in turn, reference their fathers, thus the the history is built.

As long as a commit is referenced by "something", it is guaranteed to never disappear. This "something" could either be a tag, a branch, another commit or the reflog of a given branch. When it no longer is, however, Git will let its garbage collector scavenge everything that pends and is no longer useful. Also, before actually deleting something, Git will observe first a grace period, typically three months, before deciding it's really not worth preserving it.

So the right answer here would be: "don't care about these commits, they will eventually disappear by themselves".

However, if you can see them in a git log result, as your screenshot seems to show, it's either because you're browsing a branch that still references them or because you're calling the explicit identifying hash sum of a given commit, even if it's not referenced anymore in itself.

In the former case, if what you want to do is actually remove some particular commits among a given branch, what you probably need is to rebase this branch using git rebase -i to specify what's to be saved and discarded.

If you really want to kill them all right now and forever (for instance, because you've accidently pushed porn or some confidential informations), you may take a look at this entry. Keep in mind, though, that this will only clean up your local repository. If you have already pushed stuff somewhere, you'll need an access to the concerned machine.

"git reset --hard" command does not delete unnecessary commits

3 Answers3