Open Wuestengecko opened 12 hours ago
I think the current behavior is by design, and this use case will be handled by jj sign --force
or something. https://github.com/martinvonz/jj/pull/3142
I think the current behavior is by design
That's a bit surprising. First, git with commit.gpgsign = true
behaves like I described (which is what led me to think this was a bug). Second, the setting is called "sign-all", and the docs also don't mention this restriction, as far as I can see.
https://github.com/martinvonz/jj/blob/main/docs/config.md#commit-signing
jj
can be configured to sign and verify the commits it creates using either GnuPG or SSH signing keys.
I can see how you could maybe interpret this to mean it only signs new commits (as in, created with jj new
, but not ones fetched from a remote and then edited). But then again, it will verify everything that has a signature, and not re-signing after making changes also kind of defeats the purpose - whether a signature is trustworthy is an entirely different discussion.
Also, the argument was made that people are gonna want the "Verified" chip on Github. I'm one of those people. :)
cc @necauqua
(I agree the doc is unclear.)
Huh, I'm pretty sure that by that design point 2 should've failed to complete, since the idea was that automatically rewriting and resigning someone elses commits may be undesirable.
Oh, maybe that other commit was not signed, and we just don't sign it too then?. That does sound weird. I need to revisit it all, was a while, I'll come back later
Description
With
signing.sign-all = true
, jj does not sign commits that someone else originally authored, after I made changes to them (like editing the description).Steps to Reproduce the Problem
jj config set --user signing.sign-all true
git log -1 --format=fuller --show-signature `jj log --no-graph -r@ -Tcommit_id`
Expected Behavior
The commit is signed (with my key, as I am the Committer)
Actual Behavior
The commit is not signed
Specifications