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

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

 


--

[ message continues ]

By this I actually meant that you should "Reply to All", not just the


No. The "racy" situation is not something that is bad. It's merely a
situation where git cannot decide from stat information alone whether a
file was changed or not. So it plays safe, and looks also at the content.

But if you lie about the index's timestamp, then git will think that all

No, you cannot if you are on a "fast" machine, where the touch happens in
the same second that the index file was written. But you can wait one
second before you touch the files. Depending on the volume of your total
data, this might actually be faster as long as you touch only selected files.

-- Hannes
--

[ message continues ]