git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).