[jgit-dev] Understanding Racy Git Handling in JGit: persisting smudged e

[Christian Halstrick <christian.halstrick@xxxxxxxxx>]

why does JGit smudge the modification time of index entries
differently than native git? Native git truncates the cached length to
0, while JGit smudges the timestamp to a maximum value. Although we
don't see any problem with that we are wondering why this has been
done. We found the following comment in
DirCacheEntry.smudgeRacilyClean() :

		// We don't use the same approach as C Git to smudge the entry,
		// as we cannot compare the working tree file to our SHA-1 and
		// thus cannot use the "size to 0" trick without accidentally
		// thinking a zero length file is clean.
		//
		// Instead we force the mtime to the largest possible value, so
		// it is certainly after the index's own modification time and
		// on a future read will cause mightBeRacilyClean to say "yes!".
		// It is also unlikely to match with the working tree file.
		//
		// I'll see you again before Jan 19, 2038, 03:14:07 AM GMT.

We don't understand fully that comment. Additionally: shouldn't it be
very cheap to detect whether a zero-length file is clean or not? The
SHA-1 for an empty file should be constant?

Matthias & Chris