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. That commit may not even be *yours*. You may have pulled it from a sub-lieutenant as a fast-forward, or similar. Amending it later would be actively very very *wrong*. So quite frankly, I think the stuff in pu (or next?) is completely mis-designed. Doing it in the commit is wrong for fundamental reasons, which all boil down to a simple issue: - you absolutely *need* to add the signature later. You *cannot* do it at "git commit" time. That's a fundamental issue both from a "workflow model" issue (ie you want to sign stuff after it has passed testing etc, but you may need to commit it in order to *get* testing), as well as from a "fundamental git datastructures" issue (ie you would want to sign commits that aren't yours. "git commit --amend" is not the answer - that destroys the fundamental concept of history being immutable, and while it works for your local commits, it doesn't work for anybody elses commits, or for stuff you already pushed out. And "add a fake empty commit just for the signature" is not the answer either - because that is clearly inferior to the tags we already had. I dunno. Did I miss something? As far as I can tell, the signed tags that we've had since day one are *clearly* much better in very fundamental ways. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html