7

I have an interesting problem at hand. In a shared team repo, a team member added a remote to a completely unrelated repository (this was an accident).

e.g.

git remote add foreign-remote https://github.com/some-open-source-project

He checkout out the master branch of that repo and pushed it to our repo.

e.g.

git checkout foreign-remote/master
git checkout -b experiment
git push origin experiment

This created effectively two unrelated sub-graphs within the team repo:

two sub-graphs

The left part is our proper code, the right part is that foreign repository.

How can we completely remove that right part? It is not causing any harm but it is very annoying and I would like to get rid of this sub-graph, preferably without leaving any traces behind.

Also, is there a way of preventing this from happening?

Nikolaos Georgiou
  • 2,434
  • 1
  • 22
  • 28

1 Answers1

10

Remove the branches that points to the wrong graph from the remote. In your case it is experiment.

git push origin :experiment

If other developers already fetched that branch they must do a

git fetch --prune

In more detail

     A                         F
    /|\                        |
   B C D                       G
    \|/                        |
     E <-- origin/master       H <--- origin/experiment

Now if you remove the experiment branch from origin then commit H will not be referenced anymore. Thus the commits F-G-H will be deleted on a git gc.

After you removed it from the remote. The developers who already fetched it must do a git fetch --prune to remove the remotes that no longer exists.

Make a backup clone if you want to feel safer

Also, is there a way of preventing this from happening?

Use gerrit code review. It let you define fine-grained access rights and you can reject a changeset on review. Thus the wrong commits would be discarded and not get integrated in your repository.

René Link
  • 38,761
  • 11
  • 84
  • 115
  • Thanks, this definitely pointed me to the correct direction. I deleted branches and tags. Then I had to see the reflog as well, I found some useful commands to verify that it works fine: git fsck --unreachable --no-reflogs will tell me about all the commits that are unreachable git gc --prune=now will kill them and running the fsck command again verifies that there's nothing left that is unreachable :-) – Nikolaos Georgiou May 13 '15 at 11:24
  • Found some useful information here too http://stackoverflow.com/questions/3765234/listing-and-deleting-git-commits-that-are-under-no-branch-dangling – Nikolaos Georgiou May 13 '15 at 11:26