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.
From: Alex Riesen <hidden> Date: 2016-06-15 22:45:28
2008/10/9 [off-list ref]:
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)
From: Stefan Karpinski <hidden> Date: 2016-06-15 22:45:28
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 [off-list ref] wrote:
2008/10/9 [off-list ref]:
quoted
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
' --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.
--
From: Björn Steinbrink <hidden> Date: 2016-06-15 22:45:28
On 2008.10.10 05:38:25 -0400, marcreddist@aim.com wrote:
quoted
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
From: Stefan Karpinski <hidden> Date: 2016-06-15 22:45:28
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 [off-list ref] wrote:
On 2008.10.10 05:38:25 -0400, marcreddist@aim.com wrote:
quoted
quoted
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