Rewriting a GitHub repo

[keithlayne]

Docs are great, and they say:

The server may not allow you to force push over some refs. For example, code review systems may have special ref namespaces (e.g. refs/changes/, refs/pull/, refs/merge-requests/) that they have locked down.

Should I read this as proof that I can't force-push or use --mirror on an existing repo and expect GH PRs to survive, or for things to even not fail spectacularly?

There are some other human-based considerations that you cover pretty well in the docs. Basically, I have a tiny team, and it's mostly just me using git day-to-day. I can make the others re-clone without too much issue I think, but I'd honestly like to keep the repo as intact as possible.

What's generally the best alternative? I was thinking maybe rename and archive the original repo with a link. Part of me was hoping that I could rename master as part of this and maybe have it be even more seamless, maybe write a script and tell everyone to run it after the rewrite to kill off all the bad local refs but keep continuity in dev environments.

My main goal for using git-filter-repo is to totally remove some big high-churn files from the repo so it doesn't just have unbounded growth forever - in this case I really need the upstream to be shrunk. Seems like if refs/pull/* are protected, then quite possibly I can't actually remove lots of that cruft. Anyway, I welcome any advice.

[newren]

Right, you'll be unable to remove refs/pull/* so the server side storage wouldn't actually shrink. refs/pull/* aren't cloned/fetched by default, so you could potentially choose to just "deal with it" and push the things that you can. Anyone that reclones would get the smaller size history, unless they also manually fetched refs/pull/. However, if there are any open pull requests at the time of the rewrite, attempting to merge them after rewriting history would cause you to combine the old and new histories (essentially ending up with two copies of all commits, one of the commits being ones that contained big high-churn files in their history). Also, anyone who fetched refs/pull/ and attempted to merge it would result in you having two combined histories. Once you have two combined histories, things get a bit messier to try to clean up, so I usually suggest people take efforts to avoid the problem and a new repository tends to help avoid it. However, a new repository is not strictly necessary.

[keithlayne]

Awesome, thanks. I actually did a test run with a dummy repo and felt pretty okay with the results. Thanks for the caveat about open pull requests, I don't think I realized that. Now I just need to figure out how to move all that stuff to a shallow submodule without breaking anyone :)