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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-listOn 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. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 -- 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.