{"thread":{"id":"6384","subject":"Re: Commit signing","startedAt":"2007-01-15T13:01:57Z","lastAt":"2007-01-15T16:47:46Z","messageCount":3,"participants":["Nicolas Pitre","Horst H. von Brand","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"31730","messageId":"200701151301.l0FD1vPg007623@laptop13.inf.utfsm.cl","threadId":"6384","inReplyTo":"andyparkins@gmail.com","subject":"Re: Commit signing","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2007-01-15T13:01:57Z","receivedAt":"2007-01-15T13:01:57Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> wrote:\n\n[...]\n\n> Again true.  What has that to do with Git though?  Why shouldn't Git have \n> features that let people with different methods of development from you use \n> it?\n\nAs long as nobody else ends up paying the cost...\n\n>     It is certainly true that signed commits /is/ a feature.  And it's a \n> feature that some people might want.  If there isn't a technical argument \n> against it, what does it matter?\n\nIt needs to be accomodated in the commit object format, so it means\nan(other) incompatible change there. Need to add checking for properly\nsigned commits all the way when slurping in a stream of changes. Need to\nset the whole up so it can bail out as if nothing ever happened in case one\ncommit doesn't check out (this is probably easy).\n\n> (Note: it doesn't matter enough to me that I would put the time in, I'm \n> arguing in the abstract really - should features be kept out because they \n> allow a development method we would find distasteful?)\n\nI'd vote for \"If somebody needs this bad enough, they are free to fork pgit\n('paranoid git')\", and add \"if the changes look sane, and don't screw up\nthe base (too much), we'll talk about merging back\".\n\nOpen source development, scratch your own itch, bazaar and all that.\n-- \nDr. Horst H. von Brand                   User #22616 counter.li.org\nDepartamento de Informatica                    Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria             +56 32 2654239\nCasilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513\n"},{"id":"31738","messageId":"Pine.LNX.4.63.0701151443440.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6384","inReplyTo":"200701151301.l0FD1vPg007623@laptop13.inf.utfsm.cl","subject":"Re: Commit signing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-15T13:45:51Z","receivedAt":"2007-01-15T13:45:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Jan 2007, Horst H. von Brand wrote:\n\n> Andy Parkins <andyparkins@gmail.com> wrote:\n> \n> >     It is certainly true that signed commits /is/ a feature.  And it's a \n> > feature that some people might want.  If there isn't a technical argument \n> > against it, what does it matter?\n> \n> It needs to be accomodated in the commit object format, so it means\n> an(other) incompatible change there.\n\nNo. A signature can be appended to any text (which a raw commit buffer \nis), and git allows for appending that signature before writing the object \n(which also gives it the final object name). So, no commit object format \nchange necessary.\n\nCiao,\nDscho\n"},{"id":"31729","messageId":"Pine.LNX.4.64.0701151143470.2577@xanadu.home","threadId":"6384","inReplyTo":"200701151301.l0FD1vPg007623@laptop13.inf.utfsm.cl","subject":"Re: Commit signing","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-15T16:47:46Z","receivedAt":"2007-01-15T16:47:46Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 15 Jan 2007, Horst H. von Brand wrote:\n\n> Andy Parkins <andyparkins@gmail.com> wrote:\n> \n> > Again true.  What has that to do with Git though?  Why shouldn't Git have \n> > features that let people with different methods of development from you use \n> > it?\n> \n> As long as nobody else ends up paying the cost...\n> \n> >     It is certainly true that signed commits /is/ a feature.  And it's a \n> > feature that some people might want.  If there isn't a technical argument \n> > against it, what does it matter?\n> \n> It needs to be accomodated in the commit object format, so it means\n> an(other) incompatible change there.\n\nNot really.  Nothing prevents from having a signature block at the \nbottom of the commit message, just like signed tags.\n\n> Need to add checking for properly\n> signed commits all the way when slurping in a stream of changes. Need to\n> set the whole up so it can bail out as if nothing ever happened in case one\n> commit doesn't check out (this is probably easy).\n\n... and if you don't care about the signature you may ignore it \nentirely.\n\n\nNicolas\n"}]}