On Tue, Aug 19, 2014 at 03:06:09PM -0700, Junio C Hamano wrote: > While signed tags and commits assert that the objects thusly signed > came from you, who signed these objects, there is not a good way to > assert that you wanted to have a particular object at the tip of a > particular branch. My signing v2.0.1 tag only means I want to call > the version v2.0.1, and it does not mean I want to push it out to my > 'master' branch---it is likely that I only want it in 'maint', so > the signature on the object alone is insufficient. > > [...] > > This series introduces a cryptographic assurance for ref updates > done by "git push" by introducing a mechanism that allows you to > sign a "push certificate" (for the lack of better name) every time > you push. Think of it as working on an axis orthogonal to the > traditional "signed tags". Sounds a lot like the "branch object" concept I suggest earlier, where each push would also push a commit to a branch object describing the updates to the branch, including signing of the updates to the branch (hey, it's just a signed commit), groups of commits pushed together / to be backed out together, rebase history, ... (What about pushing orphaned commits?) Code-wise, would that be more or less generic? Nico -- -- 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