Really remove a file ?

Hi,

I'm a new git user for some weeks or so and well i think git is awesome. I didn't read all the online docs and mans yet, but i'm already really impressed by it's power. Thanks everyone for this helpful tool.

Right now i think i need some help. I started to work for a project, and everything went fine. But I noticed someone placed a huge data file in the repository. This file shouldn't have been here at the first place. So I deleted it with git-rm. But that wasn't clever because now, "git log -p" or "git log -S'something'" are really really slow. Also diffs are huge and lots of command results are hard to read.

So is there a way to really remove a file in the git repository so that it never existed (I mean not having the diff in the logs and the data stored somewhere in the .git directory) ? Or if it's not the was git is supposed to be used, is there a way to hide the diff (even from git-log) or something ?

Thank you again,

--

Marc R.

2008/10/9  <marcreddist@aim.com>:

Yes. But you'll change the whole history (of course, it should _never_ mention the file). See git filter-branch (there is even an example at the end of its man page. Replace mv with rm)

Specifically, you probably want to do something like this:

  $ git filter-branch --index-filter 'git update-index --remove
<filename>' --force -- --all

Beware that this will make your repository effectively "incompatible" with those of others who've pulled from you before—because all of your history is now completely rewritten. You should probably have them clone a new copy from the repo you've run this on instead of trying to continue working with their old repos. Otherwise all hell breaks loose. You'll probably also want to run "git gc" on your repo to actually get rid of the huge object that was added (or does filter-branch do this automatically?).

On Thu, Oct 9, 2008 at 11:56 AM, Alex Riesen <raa.lkml@gmail.com> wrote:

Hi,

Thank you both, that's exactly what i needed.

In case someone finds this post in the future, this :

' --force -- --all

worked perfectly. Although, it told me that git can't work on a dirty directory so I did this :

$ git add .

$ git commit

And after the filter-branch

$ git reset --hard HEAD^

I'm not sure it's required by git-filter-branch alone. In this case :

git-gc saves almost 5% after the file deletion

it saves 4.5% before the file deletion

If I run git gc before and after the git filter-branch, it saves 4.5% and then 0.2%.

But maybe my tests applies to my particular environment and cannot be generalized.

Thank you again for the help.

Take care,

Marc, happy git user.

On 2008.10.10 05:38:25 -0400, marcreddist@aim.com wrote:

Did you clear the refs/original namespace and your reflogs? Otherwise, the huge object is most likely still referenced and thus won't get pruned. Also, I usually prefer "git repack -adf" over "git gc" in such situations, but that's probably just because I don't know the right way to force "git gc" to immediately prune stuff just once.

But don't do the pruning until you're absolutely sure that you don't require the old stuff anymore.

Björn

Or, of course, you could just keep an independent copy of the whole repo pre-filter-branch.

On Fri, Oct 10, 2008 at 7:32 AM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote: