{"thread":{"id":"52892","subject":"Making GitGitGadget conversion lossless","startedAt":"2020-02-26T20:09:39Z","lastAt":"2020-02-26T22:27:11Z","messageCount":5,"participants":["Konstantin Ryabitsev","Junio C Hamano","Vegard Nossum"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"392560","messageId":"20200226200929.z4aej74ohbkgcdza@chatter.i7.local","threadId":"52892","inReplyTo":null,"subject":"Making GitGitGadget conversion lossless","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2020-02-26T20:09:29Z","receivedAt":"2020-02-26T20:09:39Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"Hi, all:\n\nGitGitGadget is great, and I'm looking forward to adapting it to Linux \nKernel's needs. There is one area where I think the situation can be \nfurther improved, and that's if the process of converting a pull request \ninto a patch series were completely 100% reversible. As of right now, \nthe following data is permanently lost from commits as they are \nconverted into patches:\n\n- parent/tree hashes\n- author/committer information\n- cryptographic attestation (gpgsig)\n\nThere is an existing body of work done by Vegard Nossum [1] that makes \nit possible to fully reconstruct a git commit from an email message, and \nI hope that it can make its way into official upstream. If that were to \nhappen, it would mean that converting from a pull request into a patch \nseries would become a lossless operation and tools like GitGitGadget \nwould be able to preserve full cryptographic attestation of commits.\n\nVegard, if there is interest in getting this work into upstream, are you \nin a position to continue your work on it?\n\nBest regards,\n-K\n\n[1]: https://lore.kernel.org/git/20191022114518.32055-1-vegard.nossum@oracle.com/#t\n\n"},{"id":"392575","messageId":"xmqq5zfthxlw.fsf@gitster-ct.c.googlers.com","threadId":"52892","inReplyTo":"20200226200929.z4aej74ohbkgcdza@chatter.i7.local","subject":"Re: Making GitGitGadget conversion lossless","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-02-26T21:01:15Z","receivedAt":"2020-02-26T21:01:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:\n\n> - parent/tree hashes\n\nIsn't this already available by recording the base-commit\ninformation?\n\n> - author/committer information\n> - cryptographic attestation (gpgsig)\n\nI think you are aiming to come up with bit-for-bit identical commit\nthe sender had, and I would imagine that the easiest and least\ndisruptive way to do so is to add a compressed and ascii-armored\ncopy of \"git cat-file commit\" output of the original commit after\nthe \"---\" line before the diff/diffstat of the e-mailed patch.  The\nreceiving end can then act on it when given some option by\n\n - first recover the contents of the commit object (call it #1);\n - learn the parent commit(s) and check out the tree;\n - apply the patch in the remainder of the patch e-mail to the tree;\n - make sure that the result of patch application gives the tree object\n   recorded in #1;\n - run \"hash-object -t commit -w\" over #1 that gives you a commit\n   object that is bit-for-bit identical.\n\nAs I said already, I do not think that the desire to get the\nbit-for-bit identical commit is compatible with the idea to discuss\ne-mailed patches---the pieces of patch e-mail will become \"you may\nlook at them, you may apply them, but it is no use to comment on\nthem to get them improved\".  So, I dunno.\n"},{"id":"392579","messageId":"51155ef5-e301-2f5d-263e-184b9ab0979d@oracle.com","threadId":"52892","inReplyTo":"xmqq5zfthxlw.fsf@gitster-ct.c.googlers.com","subject":"Re: Making GitGitGadget conversion lossless","fromName":"Vegard Nossum","fromEmail":"vegard.nossum@oracle.com","sentAt":"2020-02-26T21:32:09Z","receivedAt":"2020-02-26T21:32:19Z","isPatch":false,"sender":{"key":"vegard.nossum@oracle.com","avatar":"https://avatars.githubusercontent.com/u/24173?v=4"},"body":"On 2/26/20 10:01 PM, Junio C Hamano wrote:\n> As I said already, I do not think that the desire to get the\n> bit-for-bit identical commit is compatible with the idea to discuss\n> e-mailed patches---the pieces of patch e-mail will become \"you may\n> look at them, you may apply them, but it is no use to comment on\n> them to get them improved\".  So, I dunno.\n\nFor me, at least, the goal was to be able to store previous patch\nsubmissions in git (even if it is not merged into the main tree) so\nthat you can use git and all its tools (diff, log, blame, grep, notes,\netc.) to browse previous versions and browse discussions _and_ use the\nSHA1 as a stable identifier for a specific submission.\n\nThe point of having the stable identifier is so that the submitter can\ntake comments into account and resubmit their patchset while still\nkeeping a (stable, universal, unambiguous) reference to their previous\nsubmission.\n\nI don't see the incompatibility at all. The whole point was that the\ncurrent email workflow used by Linux and git (that includes discussion,\nfeedback, and revision) _does not need to change_.\n\n\nVegard\n"},{"id":"392580","messageId":"20200226213515.t2aa4o4nquaaz6vg@chatter.i7.local","threadId":"52892","inReplyTo":"xmqq5zfthxlw.fsf@gitster-ct.c.googlers.com","subject":"Re: Making GitGitGadget conversion lossless","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2020-02-26T21:35:15Z","receivedAt":"2020-02-26T21:35:23Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Wed, Feb 26, 2020 at 01:01:15PM -0800, Junio C Hamano wrote:\n> Isn't this already available by recording the base-commit\n> information?\n> \n> > - author/committer information\n> > - cryptographic attestation (gpgsig)\n> \n> I think you are aiming to come up with bit-for-bit identical commit\n> the sender had, and I would imagine that the easiest and least\n> disruptive way to do so is to add a compressed and ascii-armored\n> copy of \"git cat-file commit\" output of the original commit after\n> the \"---\" line before the diff/diffstat of the e-mailed patch.  The\n> receiving end can then act on it when given some option by\n> \n>  - first recover the contents of the commit object (call it #1);\n>  - learn the parent commit(s) and check out the tree;\n>  - apply the patch in the remainder of the patch e-mail to the tree;\n>  - make sure that the result of patch application gives the tree object\n>    recorded in #1;\n>  - run \"hash-object -t commit -w\" over #1 that gives you a commit\n>    object that is bit-for-bit identical.\n\nRight, I just don't want to be doing this in a separate tool. :)\n\n> As I said already, I do not think that the desire to get the\n> bit-for-bit identical commit is compatible with the idea to discuss\n> e-mailed patches---the pieces of patch e-mail will become \"you may\n> look at them, you may apply them, but it is no use to comment on\n> them to get them improved\".\n\nI disagree -- specifically from the attestation point of view. One of \nthe drawbacks of platforms like lore.kernel.org is that it creates an \nopportunity for a malicious actor to compromise it and modify patches \nthat they know will be downloaded and applied by Linux maintainers -- so \nmy goal is to ensure that we do not have to trust lore.kernel.org in \norder to trust patches downloaded from it. This means some mechanism for \nend-to-end patch attestation.\n\nThere are two avenues that I am pursuing for this purpose:\n\n1. being able to submit attestation information out-of-band, see \n   discussion here: \n   https://lore.kernel.org/workflows/20200226172502.q3fl67ealxsonfgp@chatter.i7.local/T/#u\n2. being able to preserve commit signatures as they are converted into \n   patches and back\n\nI know that it is very uncommon for patches to be applied without any \nchanges, because the maintainer would almost always add their \nSigned-off-by trailer before applying it to their tree. However, \npreserving full commit metadata allows checking cryptographic \nattestation *before* adding trailers or making any other edits, for \nexample by making a shallow clone of the worktree, applying the series \n\"verbatim\", as you describe above, and then verifying the signature at \nthe tip. If \"git verify-commit HEAD\" is successful, then the maintainer \ncan be assured that patch contents have not been modified between when \nthey left the developer's system and arrived at the maintainer's \nworkstation.\n\nThis means nobody needs to trust me or other members of the sysadmin \nteam responsible for lore.kernel.org in order to trust patches they \nretrieve from it.\n\nBest,\n-K\n"},{"id":"392583","messageId":"xmqqo8tlgf2f.fsf@gitster-ct.c.googlers.com","threadId":"52892","inReplyTo":"20200226213515.t2aa4o4nquaaz6vg@chatter.i7.local","subject":"Re: Making GitGitGadget conversion lossless","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-02-26T22:27:04Z","receivedAt":"2020-02-26T22:27:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:\n\n> On Wed, Feb 26, 2020 at 01:01:15PM -0800, Junio C Hamano wrote:\n>> Isn't this already available by recording the base-commit\n>> information?\n>> \n>> > - author/committer information\n>> > - cryptographic attestation (gpgsig)\n>> \n>> I think you are aiming to come up with bit-for-bit identical commit\n>> the sender had, and I would imagine that the easiest and least\n>> disruptive way to do so is to add a compressed and ascii-armored\n>> copy of \"git cat-file commit\" output of the original commit after\n>> the \"---\" line before the diff/diffstat of the e-mailed patch.  The\n>> receiving end can then act on it when given some option by\n>> \n>>  - first recover the contents of the commit object (call it #1);\n>>  - learn the parent commit(s) and check out the tree;\n>>  - apply the patch in the remainder of the patch e-mail to the tree;\n>>  - make sure that the result of patch application gives the tree object\n>>    recorded in #1;\n>>  - run \"hash-object -t commit -w\" over #1 that gives you a commit\n>>    object that is bit-for-bit identical.\n>\n> Right, I just don't want to be doing this in a separate tool. :)\n\nYes, and I just outlined how it can be expressed in the\n\"format-patch\" output format, and implemented on the \"am\" side, as\npart of \"git\".\n"}]}