Note: Adding the -S option all the time can be cumbersome.
In git 2.0 and later, you can add a config which will take care of that option for you.
See commit 2af2ef3 by Nicolas Vigier (boklm):
Add the commit.gpgsign option to sign all commits
If you want to GPG sign all your commits, you have to add the -S option all the time.
The commit.gpgsign config option allows to sign all commits automatically.
commit.gpgsign
A boolean to specify whether all commits should be GPG signed.
Use of this option when doing operations such as rebase can result in a large number of commits being signed. It may be convenient to use an agent to avoid typing your GPG passphrase several times.
As Apteryx commented below:
To set this globally on the command line:
git config --global commit.gpgsign true
With Git 2.27 (Q2 2020), "git rebase" learned the "--no-gpg-sign" option to countermand commit.gpgSign the user may have.
See commit 5c5bac1, commit 4369d3a, commit 9da37fe, commit ae06ba6, commit cf0ad4d, commit c241371 (03 Apr 2020) by ?oàn Tr?n C?ng Danh (``).
(Merged by Junio C Hamano -- gitster -- in commit fc3f6fd, 22 Apr 2020)
Signed-off-by: ?oàn Tr?n C?ng Danh
{cherry-pick,revert} --edit hasn't honoured --no-gpg-sign yet.
Pass this option down to git commit to honor it.
Note that "git rebase --rebase-merges"(man) did not correctly pass --gpg-sign command line option to underlying "git merge" when replaying a merge using non-default merge strategy or when replaying an octopus merge (because replaying a two-head merge with the default strategy was done in a separate codepath, the problem did not trigger for most users), which has been corrected with Git 2.30 (Q1 2021)
See commit 43ad4f2, commit 19dad04, commit ae03c97 (18 Oct 2020) by Samuel ?avoj (sammko).
(Merged by Junio C Hamano -- gitster -- in commit 73af6a4, 02 Nov 2020)
sequencer: fix gpg option passed to merge subcommand
Signed-off-by: Samuel ?avoj
When performing a rebase with --rebase-merges using either a custom strategy specified with -s or an octopus merge, and at the same time having gpgsign enabled (either rebase -S or config commit.gpgsign), the operation would fail on making the merge commit.
Instead of "-S%s" with the key id substituted, only the bare key id would get passed to the underlying merge command, which tried to interpret it as a ref.
Fix the issue and add test cases as suggested by Johannes Schindelin and Junio C Hamano.
And:
sequencer: pass explicit --no-gpg-sign to merge
Signed-off-by: Samuel ?avoj
The merge subcommand launched for merges with non-default strategy would use its own default behaviour to decide how to sign commits, regardless of what opts->gpg_sign was set to.
For example the --no-gpg-sign flag given to rebase explicitly would get ignored, if commit.gpgsign was set to true.
Fix the issue and add a test case exercising this behaviour.
Fixed in:
"git rebase --rebase-merges"(man) did not correctly pass --gpg-sign command line option to underlying "git merge" when replaying a merge using non-default merge strategy or when replaying an octopus merge (because replaying a two-head merge with the default strategy was done in a separate codepath, the problem did not trigger for most users), which has been corrected with Git 2.30 (Q1 2021), .
See commit 43ad4f2, commit 19dad04, commit ae03c97 (18 Oct 2020) by Samuel ?avoj (sammko).
(Merged by Junio C Hamano -- gitster -- in commit 73af6a4, 02 Nov 2020)
sequencer: fix gpg option passed to merge subcommand
Signed-off-by: Samuel ?avoj
When performing a rebase with --rebase-merges using either a custom strategy specified with -s or an octopus merge, and at the same time having gpgsign enabled (either rebase -S or config commit.gpgsign), the operation would fail on making the merge commit.
Instead of "-S%s" with the key id substituted, only the bare key id would get passed to the underlying merge command, which tried to interpret it as a ref.
Fix the issue and add test cases as suggested by Johannes Schindelin and Junio C Hamano.
