Ah, right.  Good catch.  I'm changing this to 2500 (2.5 seconds).

ObjectDirectory's use of 2 minutes dates back to pre-Eclipse history:

  commit 4c8d63e588212f48e7ebd09580defd9a62c73c61
  Author: Shawn O. Pearce <spearce@spearce.org>  Wed Aug 12 12:45:23 2009
  Committer: Robin Rosenberg <robin.rosenberg@dewire.com>  Wed Aug 12 15:24:37 2009
  Original File: org.spearce.jgit/src/org/spearce/jgit/lib/ObjectDirectory.java

  Fix racy condition when a repository is repacked

  If the filesystem clock granularity is sufficiently large enough it
  is possible for a repacking program such as `git repack` to change
  the same directory more than once within the same modification time.

  If JGit were to scan the directory between changes in the same
  clock step it will never see the later edits, because the directory
  modification time has not changed.

  Instead we now keep track of the last time we read the directory.
  If an object cannot be found on disk and the pack directory's last
  modified time is less than 2 minutes since the last time we read
  the directory's contents, we scan it again looking for changes.

  Worst case scenario, JGit will list the pack directory once for
  each requested missing object, until the directory has aged at
  least 2 minutes.  Most repositories modify this directory only a
  few times a week, so this is not an undue burden on the host.

I didn't have a real justification for 2 minutes, it was just a fudge number.  We can probably safely change this to 2.5 seconds.