On Mon 2019-03-25 11:27:06 +0900, Junio C Hamano wrote:
> Daniel Kahn Gillmor writes:
>
>> What do you think of my updated proposal for tag.verifyNameMatch ?
>
> Meh to slightly negative for hard-coding project-specific preference
> to the core tools. "We give you -
On Sun 2019-03-24 21:26:13 +0900, Junio C Hamano wrote:
> Daniel Kahn Gillmor writes:
>
>> I don't personally have any use case for doing such a tag rename -- you
>> mention two:
>>
>> a) wanting to call tag "foo" that you found on remote "o
On Wed 2019-03-20 23:35:48 +0100, Ævar Arnfjörð Bjarmason wrote:
> But e.g. if you've signed a v1.00 in foo.git, but also maintain bar.git
> and have a v2.00 there, I can be fooled in foo.git with your proposed
> change by having the v2.00 bar.git tag pushed to it (just, with the
> proposed change,
Thanks for the thoughtful feedback, Junio!
On Thu 2019-03-21 10:31:59 +0900, Junio C Hamano wrote:
> The other point still stands; there are legitimate reasons people
> would want to have a tag with v1.0.0 tagname in somewhere that is
> not refs/tags/v1.0.0 and an extra validation must need to mak
Hi Santiago--
On Wed 2019-03-20 10:20:57 -0400, Santiago Torres Arias wrote:
> This has been known for a whlie now[1]. The consensus back then was that
> this information was up to higher-level integrators to verify using
> means like e.g., --format.
>
> [1] https://public-inbox.org/git/xmqqk2hzld
8ae6a246bef5b5eb0684e9fc1c933a4f8441dadd
type commit
tag v0.0.3
tagger Daniel Kahn Gillmor 1528706225 +0200
this is my tag message
gpg: Signature made Mon 11 Jun 2018 04:37:05 AM EDT
gpg:using Ed25519 key
C90E6D36200A1B922A1509E77618196529AE5FF8
gpg
6 matches
Mail list logo