Cyril Brulebois wrote: > since the second argument of commit would be a treeish, is that correct?
Yes. (Although it looks like it won't be able to use the tarball created by git-archive directly, since git-archive does not provide a way to order the files correctly. Also since I don't want to rely on the git guys to not add or change special pax headers that would break reproducing the exact same tarball later. Oh well, it'll just be a bit slower.) > 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). Yes, madcoder has helped me figure out how to initially populate and update the 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. Yes, exactly the plan. > 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. I'll consider adding such a backwards compatability flag, not sure yet. -- see shy jo
signature.asc
Description: Digital signature
