Can the documentation go in an git submodule?
Wouldn't this effectively be the same as having separate commits for the documentation (except with a bit of extra overhead)? As I understand it ewaller is trying to achieve it all in one commit to be 'atomic' in the sense of documentation always matching code.
My hack around this would be to use the the hash of the parent commit instead, which would still preserve some degree of identifiability assuming you don't make a practice of rewriting git history (if you did all this wouldn't really make sense anyway).
]]>Although in hindsight I'm realizing how unversed I am in git: different branches can be receiving commits indepdendenty and be merged later. So perhaps a commit number would change.
]]>Sorry if this is a silly question, but is using the hash - as opposed to the commit number - a hard requirement?
No, not really. But, the code we deliver to our customer has to be demonstrably the same as that which we qualified. What are you thinking?
I could just break down and document a hash of each file in a configuration index -- but I am trying to a bit more elegant.
Edit: Reworded.
]]>Since the git hash uniquely identifies the contents of the commit including the commit message and the hashes of the files, it is impossible to self-reference without cracking the hash and making it useless.
Edit: If the commit id isn't important in the git repository itself, but for archives created with an export, then you can use the export-subst attribute and replace a few placeholders. If you need it for your working directory checkout as well, then smudge/clean filters might work.
https://git-scm.com/book/en/v2/Customiz … Attributes
If all else fails, I'll document the snot out of it
Edit: Ironically, this is in an effort to actually get Arch into a product instead of Debian or Red Hat.
]]>I am creating documentation for a program that needs to identify the hash of a git commit to identify a specific set of files that are subsequently tested. I also want to have that file in the git repository. Which turns into a chicken vs egg thing. One cannot know the hash to bake into the document until after the document is committed.
Any suggestions, or am I barking up the wrong tree?
]]>