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! > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
