On Wed, May 18, 2016 at 3:12 PM, Michael Scherer <mscherer@xxxxxxxxxx> wrote:
Le mercredi 18 mai 2016 à 05:35 -0400, Prashanth Pai a écrit :
> Hi all,
>
> I tried out BFG tool on my github fork of glusterdocs project.
>
> $ git count-objects -vH | grep size-pack
> size-pack: 62.88 MiB
>
> $ cd ..
> $ java -jar bfg-1.12.12.jar --delete-files '*.{odp,pdf}' glusterdocs.git
> $ cd glusterdocs.git
> $ git reflog expire --expire=now --all && git gc --prune=now --aggressive
>
> $ git count-objects -vH | grep size-pack
> size-pack: 2.52 MiB
>
> As seen above, the repo size was reduced from around 62MB to 2.5MB.
>
> Caveat:
> If we do go with this approach, as git history is re-written, every
> contributor will have to re-fork the "cleaned" repo. There are about
> 60 forks now on github. Consequently, anyone sending a PR will now
> have to create a fresh clone.
>
> Is this "reset" worth it given the slight confusion and one-time
> inconvenience to contributors ? Thoughts ?
I would vote +1. Having too much binary is a pain.
Alternatively, we can make a 2nd repo after clean-up, and direct people
to the new repo, it would be less pain (cause you just fork once, no
need to do complicated git stuff, or remove the repo to fork again on
github, especially since github ask to confirm and stuff before removing
a repo)
--
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS
All in favor of the 'everyone working on this should clone again' approach.
- amye
Amye Scavarda | amye@xxxxxxxxxx | Gluster Community Lead
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
