...when they aren't traversed in the original tree.
What's the Problem?
The original implementation worked for the first submission by a student. However, when traversing a range of commits (which we do for every subsequent submission by a student), the Jgit library would throw an error when attempting to read the heading information from commits which were not included in the original range. This happens on the first commit in the range who's parent is the head hash from the previous submission.
The problem appears to be that JGit only loads the commit information for selected commits, and marks all other as "uninteresting." Uninteresting commits exist and their hashes can be viewed, but no details can be extracted from them. This is what causes the Jgit library to end up throwing a Null-Pointer Exception when accessing b which is the buffer.
What's the Solution?
This PR addresses this issue by guaranteeing that all parent commits have this buffer information before proceeding with processing. Because revWalk.parseCommit is an expensive operation, we take all measures to preserve any already extracted information before parsing the information again.
How has it been tested?
Minimal reproduction
Passoff Phase0 grading on a repo as a student.
This results in the commit verification using a non-null tailHash and excluding some commits from subsequent commit verification.
Author new commits
Submit the same repo for Phase 1
Notice the error thrown during commit verification
Test Scenarios
This new build has been tested with the minimal reproduction above and verified to work when submitting a new phase.
Because of the nature of the solution, the most interesting test case for this PR is one where the first commit after a head hash has many parents which were included in the first submission. It would be difficult for a student to create this scenario, but the scenario has been created and verified to work. The commit tree looks like this:
Notice that the two octo commits, are really octo merges that each have the same 10 parents!
This results in the first commit post submission have many parents. Interestingly, in testing, sometimes, the first 7 commits would have their buffers populated, but the last three still needed data populated. The code works properly in this case as it will for all cases now.
...when they aren't traversed in the original tree.
What's the Problem?
The original implementation worked for the first submission by a student. However, when traversing a range of commits (which we do for every subsequent submission by a student), the Jgit library would throw an error when attempting to read the heading information from commits which were not included in the original range. This happens on the first commit in the range who's parent is the head hash from the previous submission.
The problem appears to be that JGit only loads the commit information for selected commits, and marks all other as "uninteresting." Uninteresting commits exist and their hashes can be viewed, but no details can be extracted from them. This is what causes the Jgit library to end up throwing a Null-Pointer Exception when accessing
bwhich is thebuffer.What's the Solution?
This PR addresses this issue by guaranteeing that all parent commits have this buffer information before proceeding with processing. Because
revWalk.parseCommitis an expensive operation, we take all measures to preserve any already extracted information before parsing the information again.How has it been tested?
Minimal reproduction
tailHashand excluding some commits from subsequent commit verification.Test Scenarios
This new build has been tested with the minimal reproduction above and verified to work when submitting a new phase.
Because of the nature of the solution, the most interesting test case for this PR is one where the first commit after a head hash has many parents which were included in the first submission. It would be difficult for a student to create this scenario, but the scenario has been created and verified to work. The commit tree looks like this:
Notice that the two
octocommits, are really octo merges that each have the same 10 parents!This results in the first commit post submission have many parents. Interestingly, in testing, sometimes, the first 7 commits would have their buffers populated, but the last three still needed data populated. The code works properly in this case as it will for all cases now.