From: "Matthias Andree" <matthias.andree@gmx.de>
To: "Junio C Hamano" <gitster@pobox.com>, "Andreas Ericsson" <ae@op5.se>
Cc: "Alex Riesen" <raa.lkml@gmail.com>,
"Johannes Sixt" <j.sixt@viscovery.net>,
"Jakub Narebski" <jnareb@gmail.com>, "Jeff King" <peff@peff.net>,
git@vger.kernel.org, "Brandon Casey" <casey@nrlssc.navy.mil>,
"Sverre Rabbelier" <srabbelier@gmail.com>
Subject: Re: git-tag bug? confusing git fast-export with double tag objects
Date: Tue, 19 May 2009 13:21:58 +0200 [thread overview]
Message-ID: <op.ut6ciwjl1e62zd@balu.cs.uni-paderborn.de> (raw)
In-Reply-To: <7vtz3lnf1x.fsf@alter.siamese.dyndns.org>
Am 16.05.2009, 19:16 Uhr, schrieb Junio C Hamano <gitster@pobox.com>:
> The workflow for a such case would be:
>
> (0) I notice the signing key was somehow compromised; roll a new key,
> re-sign the tags, and send out a "I had to re-tag, and here is a
> list
> of the old and new tag object names you can use to verify" message;
>
> (1) You read such a message, You do "git for-each-ref refs/tags" to see
> the object names to check with my message, and realize that you have
> stale tags. So does Joe Dev but he may be slower to react;
>
> (2) You fetch (or ls-remote) from Joe Dev which is your preferrerd
> mirror
> of my tree and notice he hasn't updated, and let him know. In the
> meantime you fetch "git fetch --tags" from me, and verify the result
> against my message.
>
> (3) Joe Dev would do the same.
>
> That's largely manual, cumbersome, and makes everybody involved painfully
> aware of what is going on, which may be an advantage over silently
> updating with a new tag without telling anybody.
>
> But you can improve the situation without losing security by doing
> something like this.
Let's do things step by step and fix the current issue - and I fear there
won't be an easy technical solution, so let's amend to the documentation
for the nonce.
OK, what I was trying to do is rewrite history to fix up some b0rked
internal addresses. That's a repository for a mostly frozen project, which
is more a reference point than a basis for development. I had to recreate
the few tag signatures they were, and hence I used "git tag -f" without
thinking too much. I had seen the section on re-tagging, and am aware of
it, but it somehow didn't apply to my situation.
I think we ought
(1) to fix the git tag -h output and manual page for consistency, and
(2) to add a note to make users aware that they can also tag tags (the
[<object>] in SYNOPSIS may not be hint enough, as Git seems to differ
substantially from other SCM systems in this respect - so this is a
usability concern that deserves documentation).
I'll suggest something, but that can take a couple of days.
What else can we tag in Git? Commits and Tags. Is it sensible and does it
work to tag blobs or trees?
--
Matthias Andree
next prev parent reply other threads:[~2009-05-19 11:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-14 0:53 git-tag bug? confusing git fast-export with double tag objects Matthias Andree
2009-05-14 2:13 ` Matthias Andree
2009-05-14 3:18 ` Junio C Hamano
2009-05-14 9:37 ` Matthias Andree
2009-05-14 12:00 ` Michael J Gruber
2009-05-14 12:16 ` Alex Riesen
2009-05-14 12:51 ` Matthias Andree
2009-05-14 13:16 ` Alex Riesen
2009-05-14 13:39 ` Matthias Andree
2009-05-14 13:42 ` Sverre Rabbelier
2009-05-14 18:02 ` Matthias Andree
2009-05-14 19:01 ` Brandon Casey
2009-05-14 18:22 ` Jeff King
2009-05-14 22:35 ` Matthias Andree
2009-05-15 2:02 ` Jeff King
2009-05-15 12:23 ` Matthias Andree
2009-05-15 13:22 ` Jakub Narebski
2009-05-15 14:54 ` Johannes Sixt
2009-05-15 15:51 ` Alex Riesen
2009-05-15 16:14 ` Matthias Andree
2009-05-15 16:21 ` Andreas Ericsson
2009-05-15 17:40 ` Junio C Hamano
2009-05-16 7:14 ` Andreas Ericsson
2009-05-16 7:56 ` Jakub Narebski
2009-05-16 8:02 ` Andreas Ericsson
2009-05-16 17:16 ` Junio C Hamano
2009-05-19 11:21 ` Matthias Andree [this message]
2009-05-19 11:29 ` Jeff King
2009-05-16 5:07 ` Jeff King
2009-05-15 16:00 ` Daniel Cheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.ut6ciwjl1e62zd@balu.cs.uni-paderborn.de \
--to=matthias.andree@gmx.de \
--cc=ae@op5.se \
--cc=casey@nrlssc.navy.mil \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j.sixt@viscovery.net \
--cc=jnareb@gmail.com \
--cc=peff@peff.net \
--cc=raa.lkml@gmail.com \
--cc=srabbelier@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).