On Wed, Jan 18, 2012 at 03:47:11PM +0100, Goswin von Brederlow wrote: > "Thijs Kinkhorst" <th...@debian.org> writes: > > On Mon, January 16, 2012 23:26, Paul Wise wrote: > >>> I just wanted to ask how mature Package-format 3.0 (git) became until > >>> now. > >> > >> It is not currently accepted by the Debian archive: > >> http://bugs.debian.org/642801 > > > There is a lot of different opinions about wether the format is sane at > all. A problem with the basic idea/design of 3.0 (git) as opposed to the > maturity of the implementation.
It is strictly better than 3.0 (quilt). For every set of tree+patches representable by quilt, you can produce a shallow git repository that contains exactly the same bits of data and nothing more. Only metadata would differ: * git doesn't store per-file mtime (but neither does quilt for files it patches), you can't store device nodes, etc * git would preserve references to commits that are not present in the source package; you can complete them from another place. These can be deleted as well, at the cost of changing the hash. A popular misconception is that git doesn't allow fine control of what objects you ship. There's simply no porcelain for that -- no one before had such a need. Git tries hard to err on the side of efficiency and safety rather than taking the minimal possible space. Yet if you want, you can prune a repository to exactly a given set of commits. The whole issue of being sure you don't unknowingly distribute potentially non-free data can be done by either repacking the received package after upload, or alternatively checking if every object is used by one of commits present in what was uploaded and rejecting if not. And if present commits have a reference to non-present commits that happen to include non-free or otherwise inappropriate data -- what's exactly the problem? -- 1KB // Yo momma uses IPv4!
signature.asc
Description: Digital signature
