Re: [egit-dev] MissingObjectException, why does that happen?

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Thu, Feb 16, 2012 at 07:27, Thomas Hallgren <thomas@xxxxxxx> wrote:
> I'm trying to find the diff between and old commit and the current HEAD. My
> method works well but sometimes I get a MissingObjectException when I
> resolve the old tree:
>
> org.eclipse.jgit.errors.MissingObjectException: Missing unknown
> 31631c381870df87e496fc9ae5bdd624c2931621
>    at org.eclipse.jgit.storage.file.WindowCursor.open(WindowCursor.java:125)
>    at org.eclipse.jgit.lib.ObjectReader.open(ObjectReader.java:228)
>    at org.eclipse.jgit.revwalk.RevWalk.parseAny(RevWalk.java:811)
>    at org.eclipse.jgit.lib.Repository.parseSimple(Repository.java:585)
>    at org.eclipse.jgit.lib.Repository.resolve(Repository.java:389)
>    at org.eclipse.jgit.lib.Repository.resolve(Repository.java:376)
>
> The object I try to resolve is assembled as:
>
>  fullCommitID + "^{tree}"
>
> I'm not sure what I'm doing wrong. Any hints on what to look for would be
> greatly appreciated.

This happens if the object doesn't exist, or if the object exists but
the caches inside of JGit are stale and JGit didn't notice new loose
objects or new pack files being present.

Normally JGit looks at the packs it knows about, then the loose
objects, then does a stat on the $GIT_DIR/objects/pack directory to
see if packs have been added since the last time it looked. If the
mtime isn't different, it throws this exception because it can't find
the object anywhere.

We try to avoid a race condition on the filesystem mtime not advancing
"quickly enough" during rapid edits by requiring two separate scans of
the pack directory to come up with identical results, separated by
some number of seconds (5?) with the same mtime. This should work.
Unless there is something weird going on that we haven't accounted
for.

What filesystem is the repository stored on? Is it NFS? SMB? A local filesystem?