From: Matthias Andree <matthias.andree@gmx.de>
Date: Thu, 14 May 2009 00:53:42 GMT
Subject: git-tag bug? confusing git fast-export with double tag objects
Message-ID: <op.utv93sdo1e62zd@merlin.emma.line.org>

Greetings,

I found a way to break git fast-export accidentally. I'm looking at the  
master branch, currently v1.6.3.1-9-g95405ba for me.

The short story is, I tried to regenerate signed tag objects after  
doctoring the history in a repo to fix b0rked addresses after conversion,  
doing something like:

	git tag -f -s foo foo

when I should have done

	git tag -f -s foo foo^{commit}

Now I have  tag "foo" twice in my repo, and this screws some operations  
royally.

Here's a script to generate such a b0rked repo:

#! /bin/sh
#
# On your marks
set -eu
IFS=$(printf '\n\t')
#
# Set
dir=$(mktemp -d)
cd $dir
git init
echo foo >bar
git add bar
git commit -m "add bar"
git tag -s baz -m "tag bar as baz"
#
# Go - this is correct, but we'll do wrong
#git tag -f -s baz baz^{commit} -m "regenerate tag"
#
# This is wrong and confuses git fast-export:
git tag -f -s baz baz -m "regenerate tag"
#
# Print the result
git show baz


This is quite prominent in git fast-export --all --signed-tags=strip  
output:

...
tag baz
 from :2
tagger Matthias Andree <matthias.andree@gmx.de> 1242259705 +0200
data 15
tag bar as baz

tag baz
 from :0
tagger Matthias Andree <matthias.andree@gmx.de> 1242259705 +0200
data 11
regenerate

And the "from :0" hunk kills git fast-import afterwards as the mark :0  
isn't defined. Not sure if it could cope with a duplicate tag otherwise.  
Probably not how git-tag should behave.

Questions:

1. how do I get a list of all such tags? git tag -l doesn't work. git  
rev-list --all is a bit unspecific for my taste, and not very helpful...

2. how do I trash the accidentally created 2nd "baz" tag object, i. e.  
remove it from the (packed) object database? Of course, I can hack some  
script (or use a text editor) to grind this git-fast-export into shape and  
re-importing it...

3. is this a shortcoming in git tag that doesn't properly resolve its 2nd  
non-option argument to a commit?

Thanks.

-- 
Matthias Andree