Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Tue, Nov 1, 2011 at 2:56 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> But on the other hand, in many ways, publishing your commit to the outside >> world, not necessarily for getting pulled into the final destination >> (i.e. your tree) but merely for other people to try it out, is the point >> of no return (aka "don't rewind or rebase once you publish"). "pushing >> out" might be less special than "please pull", but it still is special. > > So I really think that signing the top commit itself is fundamentally wrong. It merely is a stronger form of the "committer" line in the commit object. A random repository at Github anybody can create repositories at can serve you a random commit with any random name on "committer" line, and the new gpgsig header is a way to let the committer certify it genuinely is from the committer. I do not think for that purpose, in-commit signature is fundamentally wrong. I was hoping it would be more useful than it turned out to be, but I agree that it just is not suitable as a vehicle to convey "I made that commit some time ago, and now I want you to pull it for such and such reasons" in a larger workflow. The "now I want you to pull it for such and such reasons" part is the pull request, and if we are to protect them with GPG signatures, and perhaps copy the signed part in the resulting merge, don't we have a reasonable solution, without all the downsides the signed tag approach would cause if we wanted to allow third party auditors to have access to the signatures for independent auditing purposes (described in a separate message)? Perhaps what is causing the problem is the desire to allow third party auditors finer grained audit trail, but after having heard that $DAYJOB folks went through each and every commit after known release points with fine-toothed comb, I am not brave/rude/blunt enough to dismiss it as unimportant. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html