Re: Question about --tree-filter

[Johannes Sixt <j.sixt@viscovery.net>]

[ 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