Really remove a file ?

Really remove a file ?

[marcreddist]

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.

Re: Really remove a file ?

[Alex Riesen]

2008/10/9  <marcreddist@aim.com>:
> 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 ?

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)

Re: Really remove a file ?

[Stefan Karpinski]

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:
>
> 2008/10/9  <marcreddist@aim.com>:
> > 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 ?
>
> 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)
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Really remove a file ?

[marcreddist]

Hi,



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



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

> $ git filter-branch --index-filter 'git update-index --remove

' --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^



> 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?).

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.



-- 

Re: Really remove a file ?

[Björn Steinbrink]

On 2008.10.10 05:38:25 -0400, marcreddist@aim.com wrote:
>> 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?).
>
> 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%.

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

Re: Really remove a file ?

[Stefan Karpinski]

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

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:
>
> On 2008.10.10 05:38:25 -0400, marcreddist@aim.com wrote:
> >> 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?).
> >
> > 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%.
>
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html