On Tue, Jun 05, 2007 at 08:12:44AM +0100, Peter TB Brett wrote:
> On Wednesday 13 June 2007 05:58:19 Tim Freedom wrote:
>
> > I've heard and read that git doesn't deal "well" with binary files
> > (it simply keeps copies instead of diffs)
>
> Actually, that's the way that git deals with **all** files (it keeps a full
> copy of every revision). So I'm sure you'd argue that git doesn't deal well
> with **any** files.
That's what git originally did. But pack files keep differences up to
some limits given by two parameters. From git-repack's man page:
--window=[N], --depth=[N]
These two options affect how the objects contained in the pack are
stored using delta compression. The objects are first internally
sorted by type, size and optionally names and compared against the
other objects within --window to see if using delta compression
saves space. --depth limits the maximum delta depth; making it too
deep affects the performance on the unpacker side, because delta
data needs to be applied that many times to get to the necessary
object. The default value for --window is 10 and --depth is 50.
These two parameters have a large influence on the size of the final
pack file in some cases: converting GCC trunk from svn to git with default
parameters gives a final pack size of 1.4 GB but can be brought down
to below 300MB when increasing them.
Granted the full packing with these parameters set to 100 is extremely
slow, but you don't need to do it often.
For binary files, well, try not to change them often is the first
advice. Then use the gitattributes mechanism so that it also
works on systems which need line ending conversions. Finally
admit that there are some operations that cannot be performed
on binary files for fundamental reasons, like git-blame.
Regards,
Gabriel
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
