David Lang [off-list ref] writes:
you should be able to use clean/smudge to have git store the files
uncompressed, which will help a lot.
I think there's a way to tell it to do a xml aware diff/patch, but I
don't remember how.
I do not know about "patch" (in the sense of "git apply"), but "git
diff" (and "git log -p") can take advantage of the clean/smudge
mechanism. I used to deal with a file format that is gzipped xml so
my clean filter was "gzip -dc" while the smudge was "gzip -cn".
Essentially, this stors the xml before compression in the repository
so blobs delta well with each other and also the revisions are
made textually diff-able.
Nikolaus's case has one extra layer of complexity in that the "file"
is actually an archive of multiple files. The clean/smudge pair he
writes need to be a filter that flattens the archive into a single
human-readable text byte stream and its reverse.
W dniu 16.08.2016 o 18:58, Junio C Hamano pisze:
David Lang [off-list ref] writes:
quoted
you should be able to use clean/smudge to have git store the files
uncompressed, which will help a lot.
You can find rezip clean/smudge filter (originally intended for
OpenDocument Format (ODF), that is OpenOffice.org etc.) that stores
zip or zip-archive (like ODT, jar, etc.) uncompressed. I think
you can find it on GitWiki, but I might be mistaken.
quoted
I think there's a way to tell it to do a xml aware diff/patch, but I
don't remember how.
I do not know about "patch" (in the sense of "git apply"), but "git
diff" (and "git log -p") can take advantage of the clean/smudge
mechanism. I used to deal with a file format that is gzipped xml so
my clean filter was "gzip -dc" while the smudge was "gzip -cn".
Essentially, this stores the xml before compression in the repository
so blobs delta well with each other and also the revisions are
made textually diff-able.
Nikolaus's case has one extra layer of complexity in that the "file"
is actually an archive of multiple files. The clean/smudge pair he
writes need to be a filter that flattens the archive into a single
human-readable text byte stream and its reverse.
There is also `textconv` filter that can be used instead; it might
be 'unzip -c' (extract files to stdout, with filenames), or 'unzip -p'
(same, without filenames).
--
Jakub Narębski