On 31/01/2008, Joey Hess wrote: > I've been considering adding support to pristine-tar for checking > deltas in and out of git directly.
Ah, nice. > This provides a nice simple interface, and a uniform location for > where to keep the deltas. > > Interface would be something like this: > > pristine-tar commit ../foo_1.0.orig.tar.gz tags/1.0 > pristine-tar checkout ../foo_1.0.orig.tar.gz So, it looks like one could use whatever branch scheme s/he likes, e.g.: - keeping upstream and debian/* independent of each other (achieved by simulating another initial commit), and where tarballs are injected in the upstream branch e.g. through git-import-orig. - or using debian/* branches forked from an upstream one. since the second argument of commit would be a treeish, is that correct? If that interface doesn't interfere at all with the chosen branching scheme, that looks very fine. > This also nicely offers a solution to the bug about the empty > directories, as well as some other related problems with keeping stuff > in git (ie, certian file permissions, owners, and special files that > it doesn't preserve either). The interface looks quite nice, but how would data be stored? At the moment, Pierre and I are using an “independent” pristine-tar branch where successive deltas get added incrementally. Do you plan to use something similar? And what if the deltas stored there get refreshed? You just create another commit at the tip of the branch, and always use the tip when you checkout? But indeed, it would be *very* interesting to have pristine-tar handle the bootstrap (generating an extra initial commit for a “pristine-tar” branch). If the only requirement of using pristine-tar to handle the deltas by itself is a fixed branch name, say “pristine-tar”, independent from everything else, with a fixed naming scheme, say “$(basename $tarball).delta” that looks the way to go. > Any empty directories, special files, or whatever will be included in > the delta. That would be perfect. And for people having already stored their tarballs with the current version (and which might not be able to update the deltas with the above technique), I guess that it might make sense to add a backward-compatibility flag which would create the empty directories, so that tarballs gets regenerated if needed? Once they got their original tarballs back, it's sufficient to commit them to get appropriate delta, making the use of the compatibility flag obsolete from this moment. Cheers, -- Cyril Brulebois
pgpz6s5WDLdBZ.pgp
Description: PGP signature
