Re: Question about --tree-filter

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Feb 5, 2009, 08:32 UTC
Message-ID: <498AA41D.3000609@viscovery.net>
In-Reply-To: <4989FDC6.2080404@gmail.com>

[ Don't cull Cc list, please! ]

Sergio Callegari schrieb:

> 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.

I think I know what's going on. filter-branch has this code where the tree-filter is applied:

	git checkout-index -f -u -a ||
		die "Could not checkout the index"

This command may take a while to complete, and at the end it writes the index file. At this point:

(=) Some files may have the same timestamp as the index file.

(<) Others have an earlier timestamp.

Later we have this code:

	(
		git diff-index -r --name-only $commit
		git ls-files --others
	) |
	git update-index --add --replace --remove --stdin

The files (=) are racily-clean, and are added to the database; they pass through the clean filter (rezip). The files (<) are regarded as unchanged, and are not added again, and are not rezipped.

>    find ./ -type f -exec touch \{\} \;

This could help, too, because now all files are regarded as either racily-clean (same timestamp as index file) or as changed (newer timestamp).

-- Hannes