On Tue, Nov 01, 2016 at 09:09:56AM +0800, Paul Wise wrote: > On Mon, 2016-10-31 at 17:26 +0200, Adrian Bunk wrote: > > > At that point the best solution would be an alternative source > > package format that is based on git. > > That already exists (see the dpkg-source manual page), but IIRC isn't > allowed in the archive because the ftp-masters do not want to have to > analyse the whole history of a git repository for DFSG issues.
Ie, we want the repositories pruned. Git supports incomplete repositories just fine (aka shallow clones), although I'm not aware of existing tools that would shape the pruning of an existing repository. You can "git clone --depth=X" to a temp directory but that'd result in a flat repository. It's trivial to emulate a primitive scheme like quilt with its linear stack of patches, but why bother? Neither tarballs nor quilt are anywhere close to being able to represent a preferred form for modification. Representing that, ie, a non-linear history that enables both-way code transfers between forks, meaningful bisect, etc, is much harder. Even in this crippled form, though, it is strictly better than quilt: for any given "3.0 (quilt)" source package you can produce a "3.0 (git)" package that ships the exact same set of data bits (metadata differs). Metadata-wise, both can ship arbitrary comments on patches; git doesn't allow file timestamps but that's probably better than an _inconsistent_ set of file timestamps: quilt preserves those on unpatched files but loses if there's any change. Git also gives you hash references to commits you've pruned, which you can then fill in from another repository. You also get native signing for any commit. Meow! -- A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and throw away the fruits (can dump them into a cake, etc), let the drink age at least 3-6 months.
