Mike Gerwitz <mikegerwitz@xxxxxxx> writes: > It has since improved; I'm looking for the time to update the article, > or write a follow-up. Thanks for an amusing read. We also let you merge a signed tag these days, so that in a variant of your merge scenario #2, your merge commit can carry your GPG signature, made when you do the "git merge -S $other_history" to merge $other_history you obtained from your trusted colleague, as well as the signed tag your trusted colleague made with her GPG signature. That way, upon seeing that merge, a third-party can verify that the merge was made by you, and also the history of the side branch integrated to your history with that merge is vouched by your trustred colleague. I am however not quite sure what conclusion you are trying to drive at by contrasting approaches #2 and #3. The perceived problem of approach #2, if I am reading you correctly, is that the merge is what you vouch for but the commits on the side branch are not signed so there is no way for you (as the merge creator) to point fingers to when the result of the merge turns out to be problematic. The argument for approach #3 would be that it would give you (as the merge creator) somebody to point fingers to if you forced others who ask you to pull from them to sign their commits. But I am not sure if that is the right way to look at the bigger picture. Imagine you are working on a project with two branches, maint and master. The policy adopted by the project is to use the maint branch to prepare for the next maintenance release, which should never add new features. New features are to be merged to master for the next feature release. And imagine that you made a mistake of merging somebody else's branch that adds a new feature, which happens to be perfectly done and introduces no bug, to the maint branch. Your merge is signed by your GPG key. Does it absolve you from blame if you can say with certainty (thanks to GPG keys on them) that those commits on the side branch that adds unwanted (from 'maint' policy's point of view) new feature were made by somebody else, because the project used the approach #3? Not really. How would that case be any different from the case where the side branch you merged were buggy or even malicious? After all, your GPG signature carries more weight than "Yes, I did this random merge but I did so without thinking about what damage it causes to the history by pulling in other peoples' changes". Or at least it should carry more weight to your users who trust a history having your GPG signature. "This history is coming from Mike whom we trust" is what your users expect, no? When you sign your merge with "merge -S", you are vouching for the contents of the whole tree, not just "I made this merge, but I don't have anything to do with what it pulled in." It does not really matter to the end users where the changes came from. You are certifying that "git diff HEAD^ HEAD" after making the merge is what you are pleased with by signing the merge. Having said that, what approach #3 (or merging a signed tag) does give you as the merge creator is a distrubution of trust. You may not have to be _so_ careful verifying "git diff HEAD^ HEAD" of the merge when you know you can trust the side branch you are merging into your history was done by somebody you trust. But ultimately, the responsibility lies on the person who creates the topmost merge and advances the tip of the history the users of the end product of the project considers the authoritative one. -- 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