This seems like a clear case of some errant commits. Releng tends to be the group that requires/enforces not deleting git history for valid reasons, but I suspect we can delete this content here. I'm plus +1 to cleaning this up.

.git is 633.2 MB, the working tree ~50 kB. Strong +1 to cleaning this up.

+1 from me.

-Jared

On Feb 22, 2018 3:25 PM, "Zbigniew J=C4=99drzejewski-Szmek" pagure@pagure.= io
wrote:

zbyszek added a new comment to an issue you are following:
.git is 633.2 MB, the working tree ~50 kB. Strong +1 to cleaning this up.

To reply, visit the link below or just reply to this email
https://pagure.io/fesco/issue/1848

Note that I am pretty sure we refused this in the past on IIRC the mono package which also had serveral source tar.bz2's checked in.

My recollection of the issue is that if we remove those files and rewrite history:

• All existing checkouts of that package are invalid and people will need to reclone
• All hashes in the koji database that map git hash to build are invaid and incorrect, and we no longer know what hash was used for what build.

I suppose it might be possible for someone to also write a script to re-write the koji db, but not sure how practical that is.

Also related, Patrick wrote a hook that tried to deny binary things checking into git, but it was never approved by fesco for use. I can add details if there's a renewed interest in it.

I understand the concerns with invalidating the koji hashes, but we have SRPMs for fall back sources. Fedora isn't a recreatable build project now, and we're not going to retroactively be either. Our source obligation should be covered already.

As for existing checkouts, I'm not concerned on that. People might ask questions, we answer them. It's pretty simple to explain and it's an inconvenience for them at best.

Worst case, you could copy the existing repo somewhere so those hashes/data are preserved and re-seed the repository from the latest checkout in each branch. Perhaps with a README pointing to the old repo if needed.

As for existing checkouts, I'm not concerned on that.

My thoughts exactly. The number of people inconvenienced by this is a few (the maintainers, maybe the occasional pp). And since we forbid non-ff pushed, people will notice and then it's really trivial to cherry-pick the commits to the right branch.

Worst case, you could copy the existing repo somewhere so those hashes/data are preserved and re-seed the repository from the latest checkout in each branch. Perhaps with a README pointing to the old repo if needed.

Sounds good.

After considering this a bit, I'd just drop the original repo. Instead, when rewriting history, it'd possible to add a comment about the original commit (like "(rewritten from ASDFASDFASDFASD2342343)". If somebody needs to do git archeology, they can use to look it up. No need to keep 600 MB of stuff on pagure.

If we do this, I suggest we archive the old repo somewhere.

it is not allowable to rewrite the git history, if we do we will not be able to rebuild any of the builds done from the information that is in koji

We have always said that git and lookaside is our fall back safety net. perhaps we make a read only namespace in git called archive and move the repo there. we could import the history into a replacement git repo. but likely adding a README file with an explanation should be sufficient that points people to the right place to go.

Any build in koji also includes an srpm. Theoretically, it should be possible to do the rebuild from that [*]. If the rebuild from srpm works, rebuild from dist-git would also work, but I don't think there's any scenario in which the rebuild from srpm wouldn't work if the rebuild from dist-git succeeds. So I think it's OK to lose the possibility to rebuild from a dist-git hash.

[*] I'm not convinced that such rebuild for some very old package would actually work. There's so many build failures depending on hardware, kernel versions, race conditions, etc., that I suspect that taking some srpms from 10 years ago, recreating the build root, and building would not yield the same binary rpms in many many cases. But that's orthogonal to the problem at hand.

but likely adding a README file with an explanation should be sufficient that points people to the right place to go

Yeah.

Consider me +1 to this proposal.

AGREED: Move branches with huge commits to refs/archive/ and create new sanitized branches (+6, 0, 0)