Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Feature request: Support signed commits #46

Closed
meshy opened this issue Nov 6, 2019 · 1 comment
Closed

Feature request: Support signed commits #46

meshy opened this issue Nov 6, 2019 · 1 comment
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@meshy
Copy link

meshy commented Nov 6, 2019 •
edited

I have found that git-revise strips GPG signatures from commits.

This seems better than leaving invalid signatures behind, but still seems unfortunate, especially given there is no visible warning.

Is it possible to sign revised commits as part of the revision process?
@meshy meshy changed the title Support signed commits Feature request: Support signed commits Nov 6, 2019
@mystor
Copy link
Owner

mystor commented Nov 6, 2019

The signatures are stripped from commits as I'm changing the commit, and can't just leave the old GPG signature behind. As you noted, leaving it behind would "break" the commit, as it would have an invalid signature.

It should be possible to allow git-revise to re-sign each rewritten commit with your personal GPG key. This would need to be done in a similar way to git commit -S, perhaps as git revise -S, perhaps also respecting the commit.gpgSign config variable.

Unfortunately, git-revise generates the entirety of all commit objects internally, meaning we couldn't lean on the existing implementation within git commit to handle the signing for us. Instead, logic to add signatures to commit objects would need to be added to Repository.new_commit, based on the logic in git (technical docs, do_sign_commit, sign_buffer).

It may also be possible to keep signing out of the core logic by performing a final signing pass over the modified commit stack after rewriting using existing git commands. I'm not sure how much simpler/easier that would be to implement, however.

I don't personally work with GPG signed commits often, so I'm unlikely to work on this. I'd be open to reviewing a pull-request to add support for a feature like this, though.

@mystor mystor added enhancement New feature or request help wanted Extra attention is needed labels Nov 6, 2019
@emilazy emilazy mentioned this issue May 16, 2020
Open
fjasle pushed a commit to fjasle/git-revise that referenced this issue Sep 3, 2020
Add support for GPG-signed commits (mystor#46)
76e44eb 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

TODO:
  * add support for optional '<keyid>' option argument: -S[<keyid>],
    --gpg-sign[=<keyid>]
  * write a test
  * check if merge commits are also signed properly
  * check for valid mergetag support
  * update corresponding documentation
fjasle pushed a commit to fjasle/git-revise that referenced this issue Sep 4, 2020
Add support for GPG-signed commits (mystor#46)
b68350a 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

In contrast to git-commit's options, the keyid used for signing cannot
(yet) be specified explicitly but by user.signingKey to prevent using
the committer signature as fallback.

Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
fjasle pushed a commit to fjasle/git-revise that referenced this issue Sep 4, 2020
Add support for GPG-signed commits (mystor#46)
743c9d0 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

In contrast to git-commit's options, the keyid used for signing cannot
(yet) be specified explicitly but by user.signingKey to prevent using
the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
does not cause (re)creation of GPG commit signatures.

Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
fjasle pushed a commit to fjasle/git-revise that referenced this issue Sep 4, 2020
Add support for GPG-signed commits (mystor#46)
2c20ffc 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

In contrast to git-commit's options, the keyid used for signing cannot
(yet) be specified explicitly but by user.signingKey to prevent using
the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
does not cause (re)creation of GPG commit signatures.

Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
fjasle pushed a commit to fjasle/git-revise that referenced this issue Sep 7, 2020
Add support for GPG-signed commits (mystor#46)
fa04509 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

In contrast to git-commit's options, the keyid used for signing cannot
(yet) be specified explicitly but by user.signingKey to prevent using
the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
does not cause (re)creation of GPG commit signatures.

Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
fjasle pushed a commit to fjasle/git-revise that referenced this issue Sep 7, 2020
Add support for GPG-signed commits (mystor#46)
71d197e 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

In contrast to git-commit's options, the keyid used for signing cannot
(yet) be specified explicitly but by user.signingKey to prevent using
the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
does not cause (re)creation of GPG commit signatures.

Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
fjasle pushed a commit to fjasle/git-revise that referenced this issue Sep 27, 2020
Add support for GPG-signed commits (mystor#46)
4f962a9 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

In contrast to git-commit's options, the keyid used for signing cannot
(yet) be specified explicitly but by user.signingKey to prevent using
the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
does not cause (re)creation of GPG commit signatures.

Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
fjasle pushed a commit to fjasle/git-revise that referenced this issue Sep 27, 2020
Add support for GPG-signed commits (mystor#46)
c6731fa 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

In contrast to git-commit's options, the keyid used for signing cannot
(yet) be specified explicitly but by user.signingKey to prevent using
the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
does not cause (re)creation of GPG commit signatures.

Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
fjasle pushed a commit to fjasle/git-revise that referenced this issue Sep 28, 2020
Add support for GPG-signed commits (mystor#46)
d82a986 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

The keyid used for signing can be specified by an optional argument to
'-S' or '--gpg-sign' as for git-commit; if not specified explicitly,
default key id is taken from git configuration (user.signingKey) or the
committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures all commits since COMMIT.

Heavily-contributed-by: krobelus
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
fjasle pushed a commit to fjasle/git-revise that referenced this issue Sep 28, 2020
Add support for GPG-signed commits (mystor#46)
d51f36e 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

The keyid used for signing can be specified by an optional argument to
'-S' or '--gpg-sign' as for git-commit; if not specified explicitly,
default key id is taken from git configuration (user.signingKey) or the
committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Heavily-contributed-by: krobelus
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
fjasle pushed a commit to fjasle/git-revise that referenced this issue Nov 2, 2020
squash! Add support for GPG-signed commits (mystor#46)
b772642 
Update docs/man.rst and regenerate git-revise.1

Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
fjasle pushed a commit to fjasle/git-revise that referenced this issue Nov 2, 2020
squash! Add support for GPG-signed commits (mystor#46)
7487a5d 
Call 'gpg' w/ '--status-fd=2' to prevent gpg output like 'checking the
trust db' from appearing in the signature.

Suggested-by: Nika Layzell <nika@thelayzells.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
fjasle pushed a commit to fjasle/git-revise that referenced this issue Nov 2, 2020
squash! Add support for GPG-signed commits (mystor#46)
c27deca 
Strip possible CR line endings and prefix each line with the required
leading space.

Suggested-by: Nika Layzell <nika@thelayzells.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
fjasle pushed a commit to fjasle/git-revise that referenced this issue Nov 2, 2020
squash! Add support for GPG-signed commits (mystor#46)
3a8f964 
Check whether the signature creation was successful.

Suggested-by: Nika Layzell <nika@thelayzells.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus pushed a commit to krobelus/git-revise that referenced this issue Mar 21, 2021
@krobelus
[pullreqs/73] Add support for GPG-signed commits (mystor#46)
eb0befa 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

The keyid used for signing can be specified by an optional argument to
'-S' or '--gpg-sign' as for git-commit; if not specified explicitly,
default key id is taken from git configuration (user.signingKey) or the
committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Mar 21, 2021
@krobelus
Revert "[pullreqs/73] Add support for GPG-signed commits (mystor#46)"
8d5869b 
This reverts commit adef0d27b3e9720cf3def3cd4ff9425b3a688ea0.
krobelus added a commit to krobelus/git-revise that referenced this issue Jul 30, 2021
@krobelus
Add support for GPG-signed commits (mystor#46)
35d0889 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes mystor#46
Closes mystor#73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Jul 30, 2021
@krobelus
Add support for GPG-signed commits (mystor#46)
941b470 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes mystor#46
Closes mystor#73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
cb6ba18 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
52dae34 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
d5949df 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
f27a6ce 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
2834e4c 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
03e9dfa 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
068c964 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
24031ba 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
26fefda 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
dee801f 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
3417138 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
42f929d 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
ffa7eed 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
ee9235c 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
c35e951 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
3323cf0 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
65f41bd 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
84deebb 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
52a3405 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
2eb2988 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
49ba15b 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
5556c65 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
c74a56a 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
8c7c46a 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
b3243a3 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
7ccad89 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
45e79c9 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
ba4320f 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
9aa700a 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
7a5a058 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
29da545 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
f3e763d 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
888420a 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
[gpgsign-at-last] Add support for GPG-signed commits (mystor#46)
69930b0 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for that in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is considered a modification, which
seems consistent.  This logic is applied to all commits in the
todo-list for more consistency.

The test is a bit large, but the pieces are mostly independenty.  I'm
not sure if it's worth to have a separate GPG secret key initialization
for each test, and I don't know how to share that.

Closes # 46
Closes # 73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
krobelus added a commit to krobelus/git-revise that referenced this issue Aug 2, 2021
@krobelus
Add support for GPG-signed commits (mystor#46)
c2f30a8 
GPG-sign commits if option -S/--gpg-sign is given, or if configurations
revise.gpgSign or commit.gpgSign are set to true.

Unlike Git, we do not support passing the key ID as argument.  Git's
way of accepting this optional argument is a bit weird.  It would be
awkward to try to support the same with argparse.  So it's probably
best to use a separate argument for the key ID in future.

For now, the key ID is taken from Git configuration (user.signingKey)
or the committer signature as fallback.

A call of `git-revise COMMIT --gpg-sign` w/o any changes in the index
causes creation of GPG commit signatures for all commits since COMMIT.

Conversely, if GPG signing is disabled, git-revise will remove
the signature, even if the commits were not modified otherwise.
So adding/removing a signature is just another modification, like
rewording/rebasing. This logic is applied to all commits in the
todo-list.

The test is a bit large, but the pieces are mostly independen.  Maybe
we should share the GPG initialization somehow?

Closes mystor#46
Closes mystor#73

Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
@mystor mystor closed this as completed in 06e9126 Oct 3, 2021
@grncdr grncdr mentioned this issue Feb 23, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@meshy @mystor