On Wed, Mar 9, 2011 at 5:35 PM, Ruben Laguna <ruben.laguna@xxxxxxxxx> wrote:
>> I just thought I'd mention that the git-remove-history script that you
>> mention does filter-branch on HEAD, and not using the --all parameter.
>> I thought --all was the best way to "catch all" branches in one go...
>>
>> Â Â-- Tor Arvid
>>
>
> Much faster this way, thanks Tor,
>
> But it still gives the same result 88MB
>
>
> $ git branch -a
> * develop
> Âmaster
> Âremotes/origin/HEAD -> origin/develop
> Âremotes/origin/develop
> Âremotes/origin/experimental
> Âremotes/origin/gh-pages
> Âremotes/origin/master
>
> Finally I have deleted my public repo on github, created a new one and
> pushed master and develop to the new empty one.
Ah, that's why I got only 3.6M when i cloned just now ;)
FWIW (if you still want to figure it out...) - Whatever refs that your
origin branches point to - their history and objects will *not* get
deleted by git gc/prune/whatever. So if they point to commits which
have these big jars in the history, that may be the cause. Also, when
I do filter-branch, it saves the old refs in .git/refs/original so
that I can revert it all those times when I screw it up ;)
Basically - since your "new" repo is so small, there is something in
your original repo that refers to your large objects.
Have a good night.
-- Tor Arvid
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html