Stefan Beller <stefanbel...@gmail.com> writes: > On 22.08.2014 22:33, Junio C Hamano wrote: >> Stefan Beller <stefanbel...@gmail.com> writes: >> >>> On 22.08.2014 22:03, Junio C Hamano wrote: >>>> Stefan Beller <stefanbel...@gmail.com> writes: >>>> >>>>> So there would be tags like: >>>>> master_2014_08_21 >>>>> master_2014_08_22 >>>>> ... >>>>> maint_2014_08_13 >>>>> maint_2014_08_21 >>>>> and so on. Whenever there is no tag at the tip of the branch, we'd >>>>> know there is something wrong. >>>> >>>> Who creates that tag? >>>> >>> >>>> My guess would be usability as tagging so many branches is cumbersome >>> for a maintainer? >> >> Did you answer my question? Who creates these tags? >> > > It would be up to the one who pushes, the user, or in our case you! > ... > As I wrote in the first email, I made up this workaround and wanted to > see, what's so bad about that workaround and how to overcome the > problems. And all I could find was a burden on the maintainer/user.
"burden" is not an issue, as I'll be signing the push certificate anyway when I push. A signed tag or a signed commit and signed push certificate solves two completely separate and orthogonal issues. What happens if you break into GitHub or k.org and did $ git tag maint_2014_08_22 master_2014_08_22 to create an extra tag out of the tag signed by me? If you want, you could also remove the original while at it. The goal is to let us validate without having to trust the hosting site, its management and its software, which is what creates the tag there, controls where the tag sits in refs/ hierarchy and how it is shown to the outside world. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html