Re: Question about --tree-filter

From: Sergio Callegari <sergio.callegari@gmail.com>
Date: Feb 4, 2009, 20:42 UTC
Message-ID: <4989FDC6.2080404@gmail.com>
In-Reply-To: <4989C437.4070401@viscovery.net>

Johannes Sixt wrote:

Show 35 quoted lines

> 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