Stefan Beller <stefanbeller@xxxxxxxxx> writes:
> On 22.08.2014 22:33, Junio C Hamano wrote:
>> Stefan Beller <stefanbeller@xxxxxxxxx> writes:
>>
>>> On 22.08.2014 22:03, Junio C Hamano wrote:
>>>> Stefan Beller <stefanbeller@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html