Ian Jackson wrote: > How about we ship the .orig.tar.gz, plus an rsync batched update (with > a suitably early rsync version) which turns the unpacked source into > working tree plus revision history ?
I'm afraid that due to consisting of many small gzipped compontents,
.git is not ameanable to being efficiently binary deltaed, so, you'll
still end up with approximatly 2x doubled data. This is probably true of
many revision control backends, though not all .. you might be able to
do it with CVS.
It might be possible to start with the pristine source, check it into
git, and apply a set of git packs that merges the resulting repository
forward to match the maintainer's git repository. However, I think this
could only work if the maintainer's git repository began with importing
that same pristine source[1]. Which means throwing away your git repo for
each new upstream version and starting afresh, which doesn't seem very
practical.
--
see shy jo
[1] git's sha1sums are AIUI based on the entire history of the repo,
so you can't go back and change history
signature.asc
Description: Digital signature
