Don't be specific with regard to have we map between code and requirements

In section 4.2, we talk very specifically about referencing requirements directly in Git commits using a Requirement: field in the footer.

This seems like a good idea. Git is extremely good at mapping each line in a file to a corresponding set of commits, commits are durable, and having a machine readable "field" in the commmit record would make automating tracking back to a requirement super easy. There are several drawbacks, however, including an inability to fix errors without rewriting history (which would invalidate the entire durability argument).

It might be useful to capture the idea of using a Requirement: footer as an option. But it should not be baked into the process.

The actual thing that we need to have (besides carefully avoiding overloading the word "requirement") is a means of tracing ranges of content to a requirement and back again. This could be accomplished, for example, with a file that maps from requirements to specific Git commits. Specific implementations should be considered as potential best practices.

We should definitely provide some best practices.

Are there any existing standards that do this? Or is there any ongoing work in this area that we can join?

NOTE: the comment came from Leonardo Rossetti, Michael Paulweber, Philipp Ahmann.