git repo is way too big

[readytalk]

git repo is way too big

[jentfoo]

One thing to keep in mind about moving gh-pages out of the repo, this may make it harder for travis CI to update the javadocs on build (or at minimum that process would likely want to be updated).

[dicej]

BTW, in case it wasn't obvious: rewriting history will invalidate everyone's forks and clones, so it will be very disruptive, and we'll need to make sure everyone's comfortable with that.

[sgoings]

@jentfoo - agreed.
@dicej - The gh-pages branch is actually a combination of an artifact repository and documentation. I'd suggest we move the tarballs and jars to something more suited to binary storage. That'd have the biggest bang for our buck (plus gh-pages branch history management).

[dicej]

According to the Ruby script from the Rally article I linked to, these are the top ten biggest offenders:

hello/machine.o
swt-3.7-carbon-macosx.zip
swt-3.7-cocoa-macosx-x86_64.zip
swt-3.7-gtk-linux-x86.zip
hello/hello
swt-3.7-gtk-linux-arm.zip
swt-3.7-gtk-linux-x86_64.zip
swt-3.7-gtk-linux-powerpc.zip
swt-3.7-win32-win32-x86_64.zip
swt-3.7-win32-win32-x86.zip

So it looks like we'd get a big win just by moving the zips elsewhere (and rewriting history so they're completely gone from the repo).

[sgoings]

There's no need to hold the SWT jars in the avian repository. There are a few artifact repositories that are hosting SWT in a Maven/Ivy oriented fashion.

Why are we storing a built hello world in the avian repository?

[dougborg]

We could probably set up those SWT artifacts to be hosted on Bintray if they are not available anywhere else: https://bintray.com/

[dicej]

@sgoings - everything under hello was checked in accidentally. I removed it as soon as I realized, but it's still in the history.

[blimmer]

Instead of bintray, I'd recommend using the Google Code SWT Repo like we are doing in swt-bling for resolving SWT.

[dscho]

Why not simply a dedicated repository on GitHub?

[dougborg]

+1 @l1m5's suggestion to use an existing repo to resolve the SWT artifacts.

[blimmer]

I'd much rather use the Google Code repo as opposed to duplicating the artifact hosting on GitHub. From the research I did for swt-bling, it seems that many other projects rely on this repo.

[dicej]

I'm fine with whatever as long as the versions we link to don't disappear, and the host is willing to add our non-standard build(s) (e.g. linux/arm, which the Google Code repo doesn't currently have).

[dicej]

FWIW, my fork (https://github.com/dicej/avian), which has more code, branches, etc. in it than ReadyTalk/avian, but doesn't have gh-pages, is only 15MB.

[jentfoo]

Quick (and probably obvious) thought on the gh-pages. If most the data is retained within gh-pages, and gh-pages has never been merged into master. The following could be a simple way to get rid of the history of this branch (and thus hopefully reduce size without impacting the usage of gh-pages).

• Copy the data from the branch
• Delete the gh-pages branch and push the branch deletion to origin
• Recreate the branch with the saved data from step 1
• Push new gh-pages branch with no history

[dougborg]

If you go this route (it sounds good to me), make sure you create the new
gh-pages branch as an orphaned branch:

git checkout --orphan gh-pages

see:

http://robots.thoughtbot.com/its-for-the-orphans/

Also, after deleting the old branch, is there something you have to do to
"really" delete it and git rid of the data it contained?

On Tue, Dec 24, 2013 at 4:57 PM, Mike Jensen [email protected]:

Quick (and probably obvious) thought on the gh-pages. If most the data is
retained within gh-pages, and gh-pages has never been merged into master.
The following could be a simple way to get rid of the history of this
branch (and thus hopefully reduce size without impacting the usage of
gh-pages).

• Copy the data from the branch
• Delete the gh-pages branch and push the branch deletion to origin
• Recreate the branch with the saved data from step 1
• Push new gh-pages branch with no history

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/137#issuecomment-31187823
.

[joshuawarner32]

Also, after deleting the old branch, is there something you have to do to
"really" delete it and git rid of the data it contained?

All future clones of the repository won't have the old data. At some point github and the rest of the existing clones (who haven't explicitly checked out a local copy of the old branch), will get cleaned up with an automatic 'git gc'. Anybody who has a checked-out version of the old branch will have to delete it / recreate it manually before the data goes away.

[dicej]

Useful workaround for the gh-pages problem: git clone --single-branch [email protected]:ReadyTalk/avian

[dicej]

I've updated gh-pages branch to include only the HTML, CSS, and PNG files, moving everything else to avian-web under https://github.com/ReadyTalk/readytalk.github.io. This brings the repo size down from over 100MB to 19MB. I also experimented with rewriting history to remove some accidentally-checked in binary files, but that didn't save enough space to justify the headaches and confusion of publishing a new history.