Move materials from 'railsgirls' to 'materials' repo

[keikoro]

Ticket for keeping track of which materials have already been moved from the main repository railsgirls/railsgirls to the new repository railsgirls/materials.

The idea for creating a separate repository for materials - templates for posters and other materials for events, all files not directly accessible or downloadable from http://railsgirls.com etc. - originated from the main repo having become unnecessarily big. See #567.

With two separate repositories, not every (co-)organiser wanting to change just a tiny bit of information on their own local event page has to download 500MB worth of RG-related things.

[keikoro]

• copied over all files from railsgirls > assets > materials > Posters to new repo
  (+ renamed some files, separated them into generic and location-specific, moved a logo to another folder)
• removed Posters folder from main repo

[mvz]

Are you planning to rewrite the main repository to make it smaller?

[FeliciousX]

After moving all the materials, you'll need to rewrite history to make the repository smaller. That's not an easy task D:

P.S: Accidental close and re-open issue. My bad.

[mvz]

I'm volunteering to help with the history rewriting. I've done that a lot of while making some of my private projects public.

[FeliciousX]

That's nice! I've done it once and it was a huge pain in the a--! I should start practicing 😋

[keikoro]

I've never done it so wouldn't know where to start. (: But it's good to hear that someone's willing to help with this, thank you! <3

First we'll need to move all the "materials"-y files though. As I said in the other ticket, I unfortunately won't have time to work on this again until ca. the 24th. #busybusy

[keikoro]

Question: does rewriting work (alright, well) for repos which have many contributors, like this one?

[mvz]

Yes, this works. Git will keep the original author info around. Also, there are ways to rewrite merges and such. Git's subcommand filter-branch is what I would use for that.

There are a few caveats:

• You have to be very careful that people don't send pull requests based on the 'old' master. However, they should be easy to spot since they will seem to contain all the old commits.
• GitHub will not purge the old commits from its disks since other people might still have branches that depend on them. This is not really a problem since cloning will still ignore those commits.
• You might get some empty commits if they only contain purged materials. You could get rid of those too, but then there might be merges that don't actually merge anything.

[FeliciousX]

Do you think a new ticket should be created for the history rewriting?

[FeliciousX]

Meanwhile, user who wants to clone the repository can run git clone --depth=1 . I tried it. It's 142mb (Which is a lot less than 500Mb)

[keikoro]

But how would they know they should do that? Even if we put this piece of info into the README, not everyone will see it (in time; meaning, not everyone will read the readme before cloning).

And I'm all for new/more tickets if they help keep things orderly. (: