On 3/19/24 07:12, Ludovic Courtès wrote:
Right. Like I wrote when replying to Tomas, I view this as a helper
primarily for people outside Guix itself, because Guix already has its
own hooks installed as you write.
We could discuss what to do with Guix’s own hooks, but to me that’s a
separate issue.
Fair enough, that can be addressed in a separate patch. On a related
note, this patch reminded me of an idea I mentioned in a private
thread with the security team about writing a package that provides
`guix git authenticate` as a standalone script, which can be done by
extracting the dependent modules and building just them (I have
successfully done this for the "(guix build utils)" library, for
shell-like guile scripts that have a lighter footprint than all of
guix). This will help people who are installing guix from source for
the first time. They will not have guix itself available, but it
would be easier for them to use the standalone script than to
install all of guix (which they will presumably be replacing
anyway). Is there anything else around `guix git authenticate` you
are working on that might conflict with this? I am starting to look
at it now that I have been reminded.
I spent time looking for the “right” hook and couldn’t find anything
really satisfying. Ideally, I’d want a hook that runs on ‘fetch’, for
each new reference.
Is post-merge better than post-checkout? githooks(5) says ‘post-merge’
“is invoked by git-merge(1), which happens when a git pull is done on a
local repository.” Is it actually invoked when ‘git pull’ does *not*
trigger a merge?
That gave me pause too, but I tested it with a pull that caused a
fast-forward (no separate merge commit) and it still ran the hook. I
looked for a `post-fetch` hook but couldn't find one, I agree that
would be ideal.
Very good point. Now, what would it look like?
Currently we have:
--8<---------------cut here---------------start------------->8---
[guix "authentication"]
introduction-commit = 9edb3f66fd807b096b48283debdcddccfea34bad
introduction-signer = BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA
keyring = keyring
--8<---------------cut here---------------end--------------->8---
Using this configuration format, it seems there’s no room left for a
branch name, or am I overlooking something?
Or we could take the risk of removing ‘guix’ and make it:
--8<---------------cut here---------------start------------->8---
[authentication "master"]
introduction-commit = 9edb3f66fd807b096b48283debdcddccfea34bad
introduction-signer = BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA
keyring = keyring
--8<---------------cut here---------------end--------------->8---
WDYT?
Hmm, I didn't realize that git limited the number of components
available in config names, but it looks like you're correct - my
suggestion of appending `.branch-name` caused git to produce an
error that the config was invalid.
But we don't necessarily need git to be aware of the semantic
meaning of the branch name since the value is calculated by the
guile script. So we could just use a hyphen as a separator and have
"introduction-commit-master" and "introduction-commit-feature" as
separate values unrelated to each other (aside from being in the
"guix authentication" namespace).
Regards,
Skyler