Fixing Git History after Fetching Wrong Repo

Question

I made a mistake setting up a remote on my git repo and fetched from a totally different project.

Fortunately, there was no merge, but I now have the history of 2 projects floating around in my repo and I'm trying to figure out how to get my repo back to the state it was in before I made the erroneous fetch.

I've been reading about reflog, rebase, gc and other commands trying to work out which will help me get rid of the stuff I accidentally fetched, but so far haven't got any where.

It looks like I've got the history of both projects in my repo, but they're totally independent. There are essentially 2 separate trees of commits running in parallel to each other, in fact, this is what I see in gitk when looking at all branches:

You can see that the commits in the middle are not connected to the commits at the beginning and end of the history. Date-wise, they're interleaved, but gitk doesn't show them interleaved for some reason.

The isolated commits (in the middle of the pic) are the ones I'm trying to rid myself of, and they don't appear to be attached to any branch. There's no route from any of the HEADs in my repo back to this set of commits.

So far I've tried (in order in case it makes a difference):

git remote prune
git prune
git gc
git gc --aggressive --prune=tomorrow
git remote update --prune
git fetch --all

But nothing has helped yet. Can anyone suggest how I can remove these commits from my repo?

Answer 1

You just need to remove the dangling tag (0.1.something, where something isn't visible in your screenshot) using git tag -d 0.1.something. Once this is done, the commits will be gc-able.

As long as there is a tag that reaches a commit, this commit is considered reachable and will thus persist "forever", it's effectively immune to garbage-collection until you remove any refs that point to it (branches, tags, other refs, ...)