Johannes Sixt wrote:
Sergio Callegari schrieb:
in working with the "rezip" filter for the efficient git management of
openoffice, zip and docx files, I am encountering the following problem.
Suppose that you have an existing repository and that you want to convert it
into a repository using the rezip filters: git filter-branch should be the tool
to do the conversion.
Initially I believed that once set up the appropriate .git/config filter entries
and a .git/info/attributes file tying the filter to the appropriate file types,
it would have been enough to
git filter-branch --tree-filter true tag-name-filter cat
to do the conversion.
This is also what I suggested in my original post about the rezip script.
Unfortunately, this does not seem to work as expected. Not all files get
rewritten as filtered blobs.
Before the tree-filter runs, the files are checked out (and smudged by
rezip). But they are marked as unchanged (because they were checked out
moments ago). Since your tree-filter doesn't do anything, no new blobs are
added to the index, and none of your files are cleaned by rezip.
I think your brute-force tree-filter should be
rm -f "$GIT_INDEX_FILE"
assuming that a .gitattributes file is already in all revisions.
-- Hannes
Sorry, it still is not completely clear to me... I would be very glad if
you could detail better what happens when I tree-filter. From what you
say I get the impression that no file should get a new blob. As a
matter of fact, most do (and that is why at the very beginning I thought
that --tree-filter true would have been sufficient)... only a few do not
get the new blob.
And if I experiment filter-branch again, with exactly the same
parameters, apparently some of the files that did not get the new blob
in the beginning do... which looks completely weird.
The attributes are in the info subdir of .git, so the brute force
approach should be fine. I guess that it does not make any difference
wrt to a
find ./ -type f -exec touch \{\} \;
apart from looking slightly more aggressive to the index (and faster) or
does it?
Sergio
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
