git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Tracking OpenOffice files/other compressed files with Git

From
Johannes Sixt <j.sixt@viscovery.net>
Date
Sep 9, 2008, 10:57 UTC
Message-ID
<48C6569C.60000@viscovery.net>
In-Reply-To
<loom.20080909T085002-376@post.gmane.org>
[please reply to all and keep the Cc list.]
Sergio schrieb:
Show 8 quoted lines
> Johannes Sixt <j.sixt <at> viscovery.net> writes:
> 
>> Peter Krefting schrieb:
>>> Since OpenOffice doucuments are just zipped xml files, I wondered how
>>> difficult it would be to create some hooks/hack git to track the files
>>> inside the archives instead?
>> You could write a "clean" filter that "recompresses" the archive with
>> level 0 upon git-add.
...
Show 10 quoted lines
> It could be possible to write a clean filter to uncompress before commit.
> However there is a trick with the complementary smudge filter to be used at
> checkout. If you do not smudge properly, git always shows the file as changed
> wrt the index.  Smudging correctly would mean using the very same compression
> ratio and compress method that OO uses, which can be a little tricky. I have
> tried using the zip binary both in the clean and the smudge phases and it does
> not work nicely. The smudged file is always different from the original one. One
> should probably work at a lower level to have a finer control on what is
> happening (libzip) and prepend to the uncompressed file the compression
> parameters to be restored on smudging.

You don't need to smudge the OOo file on checkout iff OOo can read a file that is "compressed" at level 0.

A file that you have just 'git add'ed must not show up as dirty even if it was processed by a "clean" filter. If it does, then this indicates a bug in git, and not that a corresponding "smudge" filter is missing or misbehaves. Yes, I have observed this with my own "clean" filter some time ago, but I have not yet tried hard enough to find a reproducible test case.

> The bigger issue is however that the clean/smudge thing can be really slow when
> dealing with large OO files.
True indeed.
-- Hannes
Previous: Michael J GruberNext: Sergio Callegari
Message 5 of 9 in “Tracking OpenOffice files/other compressed files with Git”
  1. Peter KreftingSep 9, 2008
  2. Johannes SixtSep 9, 2008
  3. SergioSep 9, 2008
  4. Michael J GruberSep 9, 2008
  5. Johannes SixtSep 9, 2008
  6. Sergio CallegariSep 9, 2008
  7. Johannes SixtSep 9, 2008
  8. Mike HommeySep 9, 2008
  9. Matthieu MoySep 9, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.