> On 9 March 2016 at 20:09, David Woodhouse <dw...@infradead.org> wrote: >> Yeah, but the important criterion is *who* the thing comes from (and >> again, a signed git tag is just as good as a set of signed emails). > > Well, it's also important to me that it's easy to apply stuff > and that it comes in a single lump that's large enough that I > don't have a lot of overhead in processing it. Sure, you could > gpg sign individual patch mails and then check signatures when > doing git am, but I don't do that because it would be a complete > pain (and I'm not sure git has built-in tooling for doing it > the way it does with gpg signed tags and merges). So I definitely > would bounce an attempt by a submaintainer to send me stuff > as a pile of signed patchmails.
Sure, pull requests are better than email in fairly much every way :) >> It *isn't* about pull vs. email. That's just the transport mechanism. >> There may be a correlation, but it isn't important. > > Right, but Laszlo didn't ask "why pull requests", he asked > "why signed pull requests", to which the answer is "because > of the trust implied by the way our workflow uses pullreqs". I believe he saw the discussion of *signed* pull requests and was concerned that pull requests were somehow dangerous in a way that required extra validation before you could touch them. When in fact that's not the case at all. The use of signatures permits personal trust to eliminate the additional checking at the time you merge -- but that's a completely orthogonal thing which *can* also apply with emails (although less easily as you observe). The background is that they currently use a workshop which enforces rebasing onto the latest master, thus leading to lost history and the potential for commits which apparently *never* worked, in cases when we *should* have a working commit and a subsequently broken merge. And I'm trying to get them to fix that and use git properly, :) -- dwmw2
