Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jgit-dev] Understanding Racy Git Handling in JGit: persisting smudged entries

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

Back to the top