Re: [jgit-dev] DirCacheEntry.mightBeRacilyClean correct?

["Shawn O. Pearce" <spearce@xxxxxxxxxxx>]

"Lay, Stefan" <stefan.lay@xxxxxxx> wrote:
> Thanks for your detailed explanation!
> 
> Now I doubt if we implemented the AddCommand right in 
> http://egit.eclipse.org/r/#change,1036.
> 
> We create a new index in memory using the DirCacheBuilder. For a changed file
> we set entry.setLastModified(f.getEntryLastModified());
> f.getEntryLastModified() returns the new lastModified() of the file.
> 
> Now, when we call builder.commit(), the DirCache.write() method
> eventually calls mightBeRacilyClean() on the entry with the
> new timestamp (mtime), which is always > smudge_s.

Ouch!

That is a bug in DirCache.  My bug too, not yours.

There is currently no way to update a clean file's last modified
time, because of this particular condition.

Thinking out loud (via email)... I wonder if we moved the smudging
logic from DirCache's writeTo() method up into the readFrom() method.
By smudging during read, applications can replace the time before
we write, and we won't muck with it.

IIRC the only reason to smudge during write rather than during read
was to avoid the unnecessary work during a read that simply scans
the index, then discards it.  But smudging during read would also
cause files to appear dirty if they are racily clean and content
isn't being checked.

Maybe we should smudge during read only if we locked?

-- 
Shawn.