Source Track: Continuity requirement is unclear

[MarkLodato]

I'm having difficulty parsing the Source Track Continuity requirement in v1.2-rc1. I suspect that most readers will not understand it or apply it correctly.

In git terminology, is the requirement that a protected branch prevent non-fast-forward updates, except through for Safe Expunging Process? Is there anything else required?

What about a reflog (again, using git terminology), keeping track of all the revisions that the branch pointed to? Is that required? If not, should it be?

[zachariahcox]

What about a reflog (again, using git terminology), keeping track of all the revisions that the branch pointed to? Is that required? If not, should it be?

I think a fully public reflog would meet the continuity requirement for a version continuity, I think it would not satisfy control continuity. RefLogs themselves do not know all that went into deciding whether the ref update was legal according to the producer's policies.

[MarkLodato]

I think a fully public reflog would meet the continuity requirement for a version continuity

Thank you for confirming that it would be sufficient. Is it necessary? In other words, if you just disallowed non-fast-forward updates but didn't expose the reflogs, would that still meet the requirements? Updating the text to make this more explicit and technical would be helpful.

Example: in the commit history A <-- B <-- C, main was updated from A to C and never pointed to B. Is it a requirement that this be somehow denoted, or is it sufficient for all prior targets of main to be reachable from main?

I think this is important for Control continuity. It might be the case that A and C were fully reviewed by B was not.

I think it would not satisfy control continuity

It's not clear to me what specifically is required for this part. As I suggested in #1459, you might want to consider folding Continiuty under Enforced Change Management Process so that you can be more explicit about what is required for this piece.

[MarkLodato]

For what it's worth, v0.1 said:

[First-parent history] In the case of a non-linear version control system, where a revision can have more than one parent, only the “first parent history” is in scope. In other words, when a feature branch is merged back into the main branch, only the merge itself is in scope.

That is probably overly prescriptive, but it's attempting to address the same issue.