[libvirt] [PATCH] git: add config file telling git-publish how to send patches
The "git-publish" tool is a useful git extension for sending patch series for code review. It automatically creates versioned tags each time code on a branch is sent, so that there is a record of each version. It also remembers the cover letter so it does not need re-entering each time the series is reposted. With this config file present it is now sufficient[1] to run $ git publish to send all patches in a branch to the list for review [1] Assuming your $HOME/.gitconfig has an SMTP server listed at least e.g. [sendemail] smtpserver = smtp.example.com Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- .gitpublish | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 .gitpublish diff --git a/.gitpublish b/.gitpublish new file mode 100644 index 0000000000..857f0d552c --- /dev/null +++ b/.gitpublish @@ -0,0 +1,3 @@ +[gitpublishprofile "default"] +base = master +to = libvir-list@redhat.com -- 2.14.3
On Wed, Apr 18, 2018 at 18:35:18 +0100, Daniel Berrange wrote:
The "git-publish" tool is a useful git extension for sending patch series for code review. It automatically creates versioned tags each time code on a branch is sent, so that there is a record of each version. It also remembers the cover letter so it does not need re-entering each time the series is reposted.
With this config file present it is now sufficient[1] to run
$ git publish
to send all patches in a branch to the list for review
[1] Assuming your $HOME/.gitconfig has an SMTP server listed at least e.g.
[sendemail] smtpserver = smtp.example.com
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- .gitpublish | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 .gitpublish
diff --git a/.gitpublish b/.gitpublish new file mode 100644 index 0000000000..857f0d552c --- /dev/null +++ b/.gitpublish @@ -0,0 +1,3 @@ +[gitpublishprofile "default"] +base = master +to = libvir-list@redhat.com
ACK As a side-question. Does git-publish have the option to send GPG-signed mails? I always wanted that, but not enough to hack it into git-send-email.
On Thu, Apr 19, 2018 at 10:55:01AM +0200, Peter Krempa wrote:
On Wed, Apr 18, 2018 at 18:35:18 +0100, Daniel Berrange wrote:
The "git-publish" tool is a useful git extension for sending patch series for code review. It automatically creates versioned tags each time code on a branch is sent, so that there is a record of each version. It also remembers the cover letter so it does not need re-entering each time the series is reposted.
With this config file present it is now sufficient[1] to run
$ git publish
to send all patches in a branch to the list for review
[1] Assuming your $HOME/.gitconfig has an SMTP server listed at least e.g.
[sendemail] smtpserver = smtp.example.com
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- .gitpublish | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 .gitpublish
diff --git a/.gitpublish b/.gitpublish new file mode 100644 index 0000000000..857f0d552c --- /dev/null +++ b/.gitpublish @@ -0,0 +1,3 @@ +[gitpublishprofile "default"] +base = master +to = libvir-list@redhat.com
ACK
As a side-question. Does git-publish have the option to send GPG-signed mails? I always wanted that, but not enough to hack it into git-send-email.
Not that I'm aware of. The only common use of GPG is for signing tags associated with pull requests. eg when you do git publish --pull, it will create a signed tag for that pull request. We don't use the submaintainer model though so that's not really relevant to us. Stefan takes features requests / patches on github/stefanha/git-publish though :-) Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thu, Apr 19, 2018 at 10:06:45AM +0100, Daniel P. Berrangé wrote:
On Thu, Apr 19, 2018 at 10:55:01AM +0200, Peter Krempa wrote:
On Wed, Apr 18, 2018 at 18:35:18 +0100, Daniel Berrange wrote:
The "git-publish" tool is a useful git extension for sending patch series for code review. It automatically creates versioned tags each time code on a branch is sent, so that there is a record of each version. It also remembers the cover letter so it does not need re-entering each time the series is reposted.
With this config file present it is now sufficient[1] to run
$ git publish
to send all patches in a branch to the list for review
[1] Assuming your $HOME/.gitconfig has an SMTP server listed at least e.g.
[sendemail] smtpserver = smtp.example.com
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- .gitpublish | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 .gitpublish
diff --git a/.gitpublish b/.gitpublish new file mode 100644 index 0000000000..857f0d552c --- /dev/null +++ b/.gitpublish @@ -0,0 +1,3 @@ +[gitpublishprofile "default"] +base = master +to = libvir-list@redhat.com
ACK
As a side-question. Does git-publish have the option to send GPG-signed mails? I always wanted that, but not enough to hack it into git-send-email.
Not that I'm aware of. The only common use of GPG is for signing tags associated with pull requests. eg when you do git publish --pull, it will create a signed tag for that pull request. We don't use the submaintainer model though so that's not really relevant to us.
Stefan takes features requests / patches on github/stefanha/git-publish though :-)
Yeah, I always wondered how to do it nicely. I have signed commits turned on, but if I take a commit that is even verified by github, (and looks great with `git show --show-signature`), I have no way how to send them using send-email so that the signing is preserved. Would be nice to know if there's a way.
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Apr 19, 2018 at 06:11:20PM +0200, Martin Kletzander wrote:
On Thu, Apr 19, 2018 at 10:06:45AM +0100, Daniel P. Berrangé wrote:
On Thu, Apr 19, 2018 at 10:55:01AM +0200, Peter Krempa wrote:
On Wed, Apr 18, 2018 at 18:35:18 +0100, Daniel Berrange wrote:
The "git-publish" tool is a useful git extension for sending patch series for code review. It automatically creates versioned tags each time code on a branch is sent, so that there is a record of each version. It also remembers the cover letter so it does not need re-entering each time the series is reposted.
With this config file present it is now sufficient[1] to run
$ git publish
to send all patches in a branch to the list for review
[1] Assuming your $HOME/.gitconfig has an SMTP server listed at least e.g.
[sendemail] smtpserver = smtp.example.com
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- .gitpublish | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 .gitpublish
diff --git a/.gitpublish b/.gitpublish new file mode 100644 index 0000000000..857f0d552c --- /dev/null +++ b/.gitpublish @@ -0,0 +1,3 @@ +[gitpublishprofile "default"] +base = master +to = libvir-list@redhat.com
ACK
As a side-question. Does git-publish have the option to send GPG-signed mails? I always wanted that, but not enough to hack it into git-send-email.
Not that I'm aware of. The only common use of GPG is for signing tags associated with pull requests. eg when you do git publish --pull, it will create a signed tag for that pull request. We don't use the submaintainer model though so that's not really relevant to us.
Stefan takes features requests / patches on github/stefanha/git-publish though :-)
Yeah, I always wondered how to do it nicely. I have signed commits turned on, but if I take a commit that is even verified by github, (and looks great with `git show --show-signature`), I have no way how to send them using send-email so that the signing is preserved. Would be nice to know if there's a way.
Based on what I've read, I don't think signatures can work with an email based patch workflow, nor with a fast-forward based process. If someone signs a patch, IIUC that covers the body, the comit message, and all the metadata including committer and author fields and parent commit hash. When you send a patch and then a reviewer applies the patch, the committer field gets changed to name of the person applying it. The parent commit hash also gets changed to whatever is HEAD when you apply it. Both these changes neccessarily invalidate any signature that could be attached to the mail. The only way I can see signatures working is if you exchange patches using "git bundle" so you're sending the full git object, not just a patch file. This will neccessitate you using merge commits in the repository, not fast-forward. So commit signatures look unusable for a development model based around exchange of patches on the list as libvirt does. They could be used to some extent with a sub-maintainer model, but only the sub-maintainers would be able to sign commits, for those going into the pull request. Individual contributors still wouldn't be able to sign in general since sub-maintainers just pull patches off the mailing list and git am them - only the final pull requests as done with merge commits. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thu, Apr 19, 2018 at 05:29:22PM +0100, Daniel P. Berrangé wrote:
On Thu, Apr 19, 2018 at 06:11:20PM +0200, Martin Kletzander wrote:
On Thu, Apr 19, 2018 at 10:06:45AM +0100, Daniel P. Berrangé wrote:
On Thu, Apr 19, 2018 at 10:55:01AM +0200, Peter Krempa wrote:
On Wed, Apr 18, 2018 at 18:35:18 +0100, Daniel Berrange wrote:
The "git-publish" tool is a useful git extension for sending patch series for code review. It automatically creates versioned tags each time code on a branch is sent, so that there is a record of each version. It also remembers the cover letter so it does not need re-entering each time the series is reposted.
With this config file present it is now sufficient[1] to run
$ git publish
to send all patches in a branch to the list for review
[1] Assuming your $HOME/.gitconfig has an SMTP server listed at least e.g.
[sendemail] smtpserver = smtp.example.com
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- .gitpublish | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 .gitpublish
diff --git a/.gitpublish b/.gitpublish new file mode 100644 index 0000000000..857f0d552c --- /dev/null +++ b/.gitpublish @@ -0,0 +1,3 @@ +[gitpublishprofile "default"] +base = master +to = libvir-list@redhat.com
ACK
As a side-question. Does git-publish have the option to send GPG-signed mails? I always wanted that, but not enough to hack it into git-send-email.
Not that I'm aware of. The only common use of GPG is for signing tags associated with pull requests. eg when you do git publish --pull, it will create a signed tag for that pull request. We don't use the submaintainer model though so that's not really relevant to us.
Stefan takes features requests / patches on github/stefanha/git-publish though :-)
Yeah, I always wondered how to do it nicely. I have signed commits turned on, but if I take a commit that is even verified by github, (and looks great with `git show --show-signature`), I have no way how to send them using send-email so that the signing is preserved. Would be nice to know if there's a way.
Based on what I've read, I don't think signatures can work with an email based patch workflow, nor with a fast-forward based process.
If someone signs a patch, IIUC that covers the body, the comit message, and all the metadata including committer and author fields and parent commit hash. When you send a patch and then a reviewer applies the patch, the committer field gets changed to name of the person applying it. The parent commit hash also gets changed to whatever is HEAD when you apply it. Both these changes neccessarily invalidate any signature that could be attached to the mail.
The only way I can see signatures working is if you exchange patches using "git bundle" so you're sending the full git object, not just a patch file. This will neccessitate you using merge commits in the repository, not fast-forward.
So commit signatures look unusable for a development model based around exchange of patches on the list as libvirt does.
They could be used to some extent with a sub-maintainer model, but only the sub-maintainers would be able to sign commits, for those going into the pull request. Individual contributors still wouldn't be able to sign in general since sub-maintainers just pull patches off the mailing list and git am them - only the final pull requests as done with merge commits.
Sure, I never meant the commits should stay signed. It doesn't really make much sense in most scenarios to have individual commits signed. Signed tag is an inherent sign for all parent commits, which is more than enough. What I wanted to have established was a way for the people receiving the commit to be able to see that it really came from me and it was not tampered with. For that case I only care about the medium (through which the commit is sent) to be covered. That's the only part of the chain where I'm missing some effort to enhance integrity and accountability. Martin
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Apr 20, 2018 at 12:22:35PM +0200, Martin Kletzander wrote:
On Thu, Apr 19, 2018 at 05:29:22PM +0100, Daniel P. Berrangé wrote:
On Thu, Apr 19, 2018 at 06:11:20PM +0200, Martin Kletzander wrote:
On Thu, Apr 19, 2018 at 10:06:45AM +0100, Daniel P. Berrangé wrote:
On Thu, Apr 19, 2018 at 10:55:01AM +0200, Peter Krempa wrote:
On Wed, Apr 18, 2018 at 18:35:18 +0100, Daniel Berrange wrote:
The "git-publish" tool is a useful git extension for sending patch series for code review. It automatically creates versioned tags each time code on a branch is sent, so that there is a record of each version. It also remembers the cover letter so it does not need re-entering each time the series is reposted.
With this config file present it is now sufficient[1] to run
$ git publish
to send all patches in a branch to the list for review
[1] Assuming your $HOME/.gitconfig has an SMTP server listed at least e.g.
[sendemail] smtpserver = smtp.example.com
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- .gitpublish | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 .gitpublish
diff --git a/.gitpublish b/.gitpublish new file mode 100644 index 0000000000..857f0d552c --- /dev/null +++ b/.gitpublish @@ -0,0 +1,3 @@ +[gitpublishprofile "default"] +base = master +to = libvir-list@redhat.com
ACK
As a side-question. Does git-publish have the option to send GPG-signed mails? I always wanted that, but not enough to hack it into git-send-email.
Not that I'm aware of. The only common use of GPG is for signing tags associated with pull requests. eg when you do git publish --pull, it will create a signed tag for that pull request. We don't use the submaintainer model though so that's not really relevant to us.
Stefan takes features requests / patches on github/stefanha/git-publish though :-)
Yeah, I always wondered how to do it nicely. I have signed commits turned on, but if I take a commit that is even verified by github, (and looks great with `git show --show-signature`), I have no way how to send them using send-email so that the signing is preserved. Would be nice to know if there's a way.
Based on what I've read, I don't think signatures can work with an email based patch workflow, nor with a fast-forward based process.
If someone signs a patch, IIUC that covers the body, the comit message, and all the metadata including committer and author fields and parent commit hash. When you send a patch and then a reviewer applies the patch, the committer field gets changed to name of the person applying it. The parent commit hash also gets changed to whatever is HEAD when you apply it. Both these changes neccessarily invalidate any signature that could be attached to the mail.
The only way I can see signatures working is if you exchange patches using "git bundle" so you're sending the full git object, not just a patch file. This will neccessitate you using merge commits in the repository, not fast-forward.
So commit signatures look unusable for a development model based around exchange of patches on the list as libvirt does.
They could be used to some extent with a sub-maintainer model, but only the sub-maintainers would be able to sign commits, for those going into the pull request. Individual contributors still wouldn't be able to sign in general since sub-maintainers just pull patches off the mailing list and git am them - only the final pull requests as done with merge commits.
Sure, I never meant the commits should stay signed. It doesn't really make much sense in most scenarios to have individual commits signed. Signed tag is an inherent sign for all parent commits, which is more than enough. What I wanted to have established was a way for the people receiving the commit to be able to see that it really came from me and it was not tampered with. For that case I only care about the medium (through which the commit is sent) to be covered. That's the only part of the chain where I'm missing some effort to enhance integrity and accountability.
Oh so you don't really need git commit signing for that then. Essentially you can just git-format the patches and do normal "email" signing when sending them, so the receipient verifies the email, rather than the commit patch. That sounds like something you could integrate into git-publish. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Apr 20, 2018 at 11:36:03 +0100, Daniel Berrange wrote:
On Fri, Apr 20, 2018 at 12:22:35PM +0200, Martin Kletzander wrote:
On Thu, Apr 19, 2018 at 05:29:22PM +0100, Daniel P. Berrangé wrote:
On Thu, Apr 19, 2018 at 06:11:20PM +0200, Martin Kletzander wrote:
On Thu, Apr 19, 2018 at 10:06:45AM +0100, Daniel P. Berrangé wrote:
On Thu, Apr 19, 2018 at 10:55:01AM +0200, Peter Krempa wrote:
On Wed, Apr 18, 2018 at 18:35:18 +0100, Daniel Berrange wrote:
[...]
> diff --git a/.gitpublish b/.gitpublish > new file mode 100644 > index 0000000000..857f0d552c > --- /dev/null > +++ b/.gitpublish > @@ -0,0 +1,3 @@ > +[gitpublishprofile "default"] > +base = master > +to = libvir-list@redhat.com
ACK
As a side-question. Does git-publish have the option to send GPG-signed mails? I always wanted that, but not enough to hack it into git-send-email.
[...]
Sure, I never meant the commits should stay signed. It doesn't really make much sense in most scenarios to have individual commits signed. Signed tag is an inherent sign for all parent commits, which is more than enough. What I wanted to have established was a way for the people receiving the commit to be able to see that it really came from me and it was not tampered with. For that case I only care about the medium (through which the commit is sent) to be covered. That's the only part of the chain where I'm missing some effort to enhance integrity and accountability.
Oh so you don't really need git commit signing for that then. Essentially you can just git-format the patches and do normal "email" signing when sending them, so the receipient verifies the email, rather than the commit patch. That sounds like something you could integrate into git-publish.
Actually this is exactly what I'm looking for. I don't really care whether the commits are signed in GIT, but I care whether the emails are sent signed. It should be easy to integrate if git is able to 'am' the signed emailed patches correctly, which I did not try yet.
participants (3)
-
Daniel P. Berrangé -
Martin Kletzander -
Peter Krempa