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

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

Sorry... first made a reply ignoring the list and then tried to
fix!
 
quoted text
> 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

 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html