6

I read that, normally, deleted branches can be resurrected.

I'm looking for a way to completely obliterate a branch.

One of the developers stuck 2Gb worth of assets inside that branch, which really is content and shouldn't be inside the repo.

Note: I've not merged it into master yet!

jub0bs
  • 60,866
  • 25
  • 183
  • 186
  • 3
    I think http://stackoverflow.com/a/25458504/1860929 could help you; You will have to do something very similar. – Anshul Goyal Feb 19 '15 at 12:42
  • @mu無 that deals with specific files. I need something simpler, rm -rf branch. –  Feb 19 '15 at 13:12
  • @salivan, you say you want a simpler solution but you may not have that option. If the problematic files were merged into another branch (`master` in your case), then they're in that branch too. You can't just delete the other branch and expect to see your repository size shrink. – ChrisGPT was on strike Feb 19 '15 at 13:49
  • Have you the option to "redo" the merge? Speaks throwing away the old merge commit and creating a new one? I might have something in mind then. – Sascha Wolf Feb 19 '15 at 14:01
  • @Zeeker yes! I can do that :) I didn't merge it in master yet. –  Feb 19 '15 at 14:25

2 Answers2

4

You should be able to do this trivially through the use of git filter-branch. E.g, assuming that the files to be removed are in a directory called content:

git filter-branch --tree-filter 'rm -rf content' --prune-empty

This will iterate over all the commits in your branch, removing the erroneous content from any commits in which it occurs.

larsks
  • 277,717
  • 41
  • 399
  • 399
4

I want to add that I personally prefer the filter-branch approach, since this doesn't involve the loss of history. If filter-branch seems too difficult to use, you can take a look at BFG Repo-cleaner which is simpler.

Nevertheless I will provide an alternative for completness sake.

Since you said in the comments, that you have the option to throw away the old merge and create a new one, I would like to suggest that you create a squash merge.

Let's assume your repository has a history similar to this.

* The merge commit [master]
|\
| * feature commit [feature]
| |
| * feature commit (the evil one)
. .
. . (some more commits)
. .
|/
*

First things first, we will undo the merge.

git checkout master
git reset --hard HEAD^

Now we merge feature again, but this time use the --squash option. When doing this, git won't create a usual merge commit (speaks multiple parents), but it will apply all changes from the feature branch and leave your working tree in a state as if a "usual" merge happened (take a look at the documentation).

git merge --squash feature

Now you can resolve possible conflicts and then simply commit the merged changes (git commit). However, note that such a merge obviously has no reference on the history of the merged branch (in this case feature); you should include that information in the commit message.

Assuming that there are no other references onto feature - except for the actual branch - you can now continue to delete the branch, followed by a garbage collection.

git branch -D feature
git gc

You have to realise that git gc will only remove the history and blobs of the feature branch, if you have no other reference pointing to them. You have to make sure that this is the case.

Important

git gc will not only remove the history of the feature branch but each dangling object. To better understand the implications and consequences I would suggest to read the Git Internals - Maintenance and Data Recovery chapter of the progit book.

Sascha Wolf
  • 18,810
  • 4
  • 51
  • 73