Large patches in git repositories

[Kacper Kornet]

On Fri, Oct 05, 2012 at 05:59:42PM +0200, Paweł Sikora wrote:
> On Friday 05 of October 2012 16:05:16 Kacper Kornet wrote:
> > Recently one email to pld-cvs was blocked due to large size of generated
> > diff. The "offending" file was gcc-branch.diff from crossmingw64-gcc
> > which is 11M.

> > Does this file include and PLD specific changes or is it just a diff
> > between released version and tip of branch in some foreign (not PLD)
> > repository? In latter case maybe it should be kept in the distfiles in
> > compressed form?


> > Right now there are following limits file sizes in git
> > repositories:

> > 1) unlimited - files *.patch, *.diff, *.spec
> > 2) 2000000 bytes  - text files
> > 3) 200000 bytes - all other files

> > so very big patches are accepted. However I wonder if it should be the
> > case.

> > Another question is if we decide to move it to distfiles should the git
> > repo be rewritten to not include history of this file and reduce repo
> > size.

> > There are other similar files. Below I include the list of every file
> > larger then 1M which its maximum size in history:

> > 24145161 gcc.git/gcc-branch.diff
> > 22482085 crossmingw64-gcc.git/gcc-branch.diff

> from branch.diff/pr-XXXX.patch point of view, ideally would be to have
> an improved %patch macro called %something with support for mirrored
> source svn/hg/git repositories (similary to distfiles).

> e.g. in gcc.spec:

> RepositoryX: svn://gcc...
> %prep
> // unpack released tarball
> %somethingX revision-range-to-apply

> such construciton should generate patch on the fly (basing on origin repo or mirrored one)
> and apply it. there's no sense in rolling big stable/branch patches through versioned plain format.

> one problem i can see is the .src.rpm (generated patch vs. archived .spec).

Another problem is that if patch was generated on the fly it would broke
the building without network connection. And it would be a waste of
resources to generate it at every build. 

In my opinion a better idea is to keep in a package a script that
generates the compressed patch,pushes it to dropin and updates
# Patch-md5:

-- 
  Kacper