On Wed, 2020-05-06 at 20:59 +0200, Pierre-Yves Chibon wrote:
On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> But I would like to note that exploded repos (or source-git repos)
> have at least two other advantages.
> 1) they consume less space than tarballs for each version because
> objects in git repo are deduplicated
> 2) instead of downloading/uploading tarballs, you can just do
> something like: git pull --rebase upstream master; git push
Just a note that this is not something you can do today since a rebase rewrite
history, so you would have to do `git push --force` which isn't allowed
So if we were to move forward with this model, we will need to find a solution
for the question that has led us to forbid force pushes until now.
Well, a way to allow force pushes would be to have a git hook that
branches the tree before the force push. (creating a branch named
something like audit-force-push-<timestamp>)
That way you can retain data for legal/auditing reasons, while allowing
every day history to be rewritten.
Not sure how "nice" that would be for an auditor that has to
reconstruct what happened over multiple force pushes that way, it also
will generate quite an amount of noisy metadata (branches), but it
If the only differences are going to be a bunch of "patch-commits" on
top of an upstream tree then you have the same level of churn you have
in dist-git + upstream objects count + these new branches metadata
noise, form the pov of space used.
RHEL Crypto Team
Red Hat, Inc