Re: [libvirt] [PATCH] git: add config file telling git-publish how to send patches

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(a)redhat.com&gt; > > > > > --- > > > > > .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(a)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.