Re: Question about --tree-filter

From: Sergio Callegari <sergio.callegari@gmail.com>
Date: Feb 5, 2009, 13:13 UTC
Message-ID: <loom.20090205T123832-998@post.gmane.org>
In-Reply-To: <498AA41D.3000609@viscovery.net>

Johannes Sixt <j.sixt <at> viscovery.net> writes:

> 
> [ Don't cull Cc list, please! ]

Sorry... first made a reply ignoring the list and then tried to
fix!

Show 24 quoted lines

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

Ok it is because of a race... now I start understanding the non-consistent behaviour between different runs! Thanks a lot for the explanation.

When you say "at the end it updates the index file" do you mean the effect of the -u switch?

And when you say "Some files have the same timestamp as the index file" do you mean that diff-index uses the stat info inside the index only if a file is "<" than the index otherwise it is directly assumed that the file is changed wrt the index content? If so, would it make sense to re-touch the index after the checkout -u so that after the checkout the index is always > than every file it contains and one always starts at a non-racy situation? With this, one could only explicitly touch those files that need to get (re)filtered and gain in efficiency... or am I still missing something?

Sergio