report app: give file contents of QCed version of files in the appendix

[jenna-a2ai]

Ways to define final QC state: 1) the state of the scientist's local repo

**_pro:_** what the author likely intends as the final milestone QC state, if no project work has continued on the branch
**_risk:_** there is no guarantee that the author's local file state matches the remote repository or the commit approved by the QCer

2) the last commit of the scientist's branch/the branch of the QC initialization commit

**_pro_** if the author forgot to associate the commit with the issue using the update function, this definition 
**_risk:_** future commits could be unrelated project work
**_risk:_** a new branch could have been created for QC feedback implementation mid-issue

3) define different final QC states for each issue. Each issue's final QC state is the most recent comparator commit in the set of comparator commits given in the issue (or the initial QC commit if there are no comparator commits)

**_pro:_** if project work continued in-between file updates, these commits aren't considered because the earliest possible final QC state is given for each issue
**risk:** trusts the author to give the final QC commit. 

 - while the comparator commit defaults to the most recent commit, the author can circumvent this for a given comment. There is no guarantee that the most recent commit will eventually be documented

  - if there is only one small requested change, this risk becomes even greater because the author has less of a tendency to confirm small or obvious changes with the QCer
**_risk:_** reproducibly of the set of files  

4) the final milestone QC commit: the most chronologically recent comparator commit out of all the issues in the milestone

**_pro:_** no risk of reproducible set of files
**_risk_**: there could still be QC commits after the most chronologically recent comparator commit
**_mitigation:_** for each file, check that file contents at final issue QC commit is the same as file contents at final milestone QC commit

- this mitigates risk for all issues except the one(s) in which the final issue QC commit is the final milestone QC commit

5) assume the final QC commit for each milestone, and let the report user confirm

**_pro:_** no risks
**_con:_** unpleasant UX - would have to do this for each milestone

[jenna-a2ai]

It seems that there's no way to handle this without an explicit manual sign-off on a final QC commit OR a QC branch

1) the report app can give a drop-down telling the user to explicitly say what the final commit is

• the problem with this is that there could be project work commits in-between qc commits 2) the report app could give the user the option to select the most up-to-date commit for each issue in the milestone
• this would solve the above problem, but it is very bad to have the final QCed state of each file at a different commit - they need to be QCed as a set for reproducibility 3) if there's a QC branch, we can just alert the user if there have been commits on the qc branch after the most chronologically recent comparator commit, the report app can prompt the user about this, and all is good.

Right now, there is not a way of verifying the actual final QC commit

[dpastoor]

longer form conversation tracked here https://a2ai.slack.com/archives/C07LYA3JLCA/p1727117830055259?thread_ts=1726859324.634579&cid=C07LYA3JLCA

[jenna-a2ai]

Issue: Given a set of comparator commits for an issue, get the most recent one

How to go about this? I can use gert::git_log(), but this output is determined by the git HEAD of the report app user by default - if a QC branch was created, or the user isn't on the given branch at the time this function is called, the set of commits might not be in the list

What if a QC branch was created halfway through the qc feedback? then the log might not contain those commits because they're on another branch (example here https://github.com/A2-ai/project_x/issues/111)

git_log() gives all commits before a commit - giving the initial QC commit wouldn't work

the only solution I can think of:

• checkout the commit (not possible with gert, will have to shell out)
• do gert::git_log(max = 1)$timestamp to get the time of the commit
• do that for every commit and just get the most recent one
• then checkout that commit for the file contents