git commit self reference

ewaller · 2018-10-24 18:02:17

I think I am out of luck on this one, so I welcome comments.

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?

progandy · 2018-10-24 18:39:06

Can you not split this in two commits? One with the changes and a follow-up commit with the test documentation?

ewaller · 2018-10-24 18:48:30

I suppose that is kind of what I am doing now. The documentation uses python-sphinxcontrib-programoutput to grab the most recent commit info, so generating the documents after the commits gets them right; and they do come from controlled source. In essence, the documentation is a commit behind. I used to have a Director of Quality that I know would have worked with me on this; he moved on to greener pastures. I am not sure the new guy will be as agreeable; he is a good man, but is still establishing his authority.

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.

Last edited by ewaller (2018-10-24 18:50:10)

progandy · 2018-10-24 19:15:33

If you do not need the commit hash, you could generate everything else in a pre-commit hook and add it to the commit. The porcelain mode of "git status" should give you the files you have to document again.

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

Last edited by progandy (2018-10-24 19:28:08)

Trilby · 2018-10-24 22:32:58

Sorry if this is a silly question, but is using the hash - as opposed to the commit number - a hard requirement?

ewaller · 2018-10-25 01:32:32

Trilby wrote:

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.

Last edited by ewaller (2018-10-25 02:24:11)

Trilby · 2018-10-25 01:44:19

If you can use a commit number, they are predictable, so you could know ahead of time what the commit number would be on the commit that will include the documentation.

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.

Allan · 2018-10-25 02:09:20

Can the documentation go in an git submodule?

ewaller · 2018-10-25 02:23:23

I have to confess, I've no idea what that is. I'll look into what that may be.

ngoonee · 2018-10-25 02:34:47

Allan wrote:

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).

Last edited by ngoonee (2018-10-25 02:36:26)

Arch Linux

#1 2018-10-24 18:02:17

git commit self reference

#2 2018-10-24 18:39:06

Re: git commit self reference

#3 2018-10-24 18:48:30

Re: git commit self reference

#4 2018-10-24 19:15:33

Re: git commit self reference

#5 2018-10-24 22:32:58

Re: git commit self reference

#6 2018-10-25 01:32:32

Re: git commit self reference

#7 2018-10-25 01:44:19

Re: git commit self reference

#8 2018-10-25 02:09:20

Re: git commit self reference

#9 2018-10-25 02:23:23

Re: git commit self reference

#10 2018-10-25 02:34:47

Re: git commit self reference

Board footer