7

Someone in my team pushed a large file to the git server and everyone in the team now has a clone of the project with the large file.

I followed the guide in http://help.github.com/removing-sensitive-data/ and it works in my local source tree as well as on the remote server. But once another person fetches the new data from the remote server, he will easily reintroduce the large file by pushing new commits to the server.

Normally a team member will do the following to share his commit with others:

git fetch origin
git rebase origin/master
git push origin

In the step of 'rebase', the old large file is reintroduced in his local commits. Of course a direct way is to demand everyone in the team to re-clone the project after I remove the large file, but not everyone would be happy to do so. I'm finding any way other than re-cloning the whole project for everyone.

Any suggestions? Thanks.

razlebe
  • 7,134
  • 6
  • 42
  • 57
stid.smth
  • 1,525
  • 2
  • 11
  • 11
  • I don't see how they will introduce the giant object if they push again. A push only pushes the objects reachable by the commits that are in any of the commits that are in the old_commit..new_commit. – Adam Dymitruk Mar 15 '11 at 03:40
  • Suppose you have a commit history A-B-C-D-E. Some guy adds the large object in commit C. Then I remove the object, rewrite the history from C and push the new history to the server by force. The history is now A-B-C'-D'-E'. Another member has already cloned the whole project at first and his local history is also A-B-C-D-E. After he fetches the new history, the local commits diverged, that is A-B-C'-D'-E' on origin/master while A-B-C-D-E on master branch. After the rebase, the new history is like A-B-C'-D'-E'-C-D-E, then he pushes to the server - the old commit C is reintroduced. – stid.smth Mar 15 '11 at 05:18

3 Answers3

3

take a look at filter-tree. You need to edit the commit that introduced the file. Once that is done, everyone can fetch. This will make non-fast-forward remote branches in their repos - each commit after removing the offending file will be different now. When they rebase their current changes on top of the new remote branches, it should not push the large object anymore.

An alternate is to do a git rebase --preserve-merges -i where you edit the offending commit.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • > "When they rebase their current changes on top of the new remote branches, it should not push the large object anymore." That's my question, in fact they did reintroduce the file again after the rebase, since the old commits still exist in their local repository. – stid.smth Mar 15 '11 at 02:32
  • if the remote is cleaned, have them clone again. – Adam Dymitruk Mar 15 '11 at 02:43
  • I know that but I'm looking for another way instead of cloning it again. – stid.smth Mar 15 '11 at 02:44
  • Why? It should be fast now that you got rid of the giant object. Back up your reflog and rerere and restore them after the clone if you want those back. – Adam Dymitruk Mar 15 '11 at 03:36
  • 1
    If you have a slow network, have one guy do it then sneaker-net it around to the other devs. – Adam Dymitruk Mar 15 '11 at 03:37
  • your reflog will be of no use anyway if your troublesome commit is at the very start of your repo – Adam Dymitruk Mar 15 '11 at 04:07
0

If the execution time of removing the large file is reasonable, you can write a script that will remove the file, instruct everyone to run the script locally after a rebase, and use a hook to check that it is not reintroduced.

Sylvain Defresne
  • 42,429
  • 12
  • 75
  • 85
0

The progit book has an elaborate example using git filter-branch (not filter-tree as the other post mentions). The chapter is here

'Removing Objects' http://progit.org/book/ch9-7.html

sehe
  • 374,641
  • 47
  • 450
  • 633