die("bad object.. for duplicate tagged tag in remote

Bear with me here, I hit this in a real repo.

If you have an annotated tag of an annotated tag, and `remote update` elects not to fetch this tag (perhaps because it has a name collision locally), then the repo ends up corrupt: you can't gc it, but fsck doesn't notice.

Two repos, named "bad" and "good":

bad$ git tag -a inner
bad$ git tag -a outer inner
bad$ git tag -d inner
bad$ git show outer
tag outer
Tagger: ...
Date:   ...

This is the outer tag.

tag inner
Tagger: ...
Date:   ...

This is the inner tag.

commit 826365dcfec304a80b227a990f7d5c805bce3dd9
Author: ...
...

bad$ git rev-parse outer 070707.. bad$ git cat-file tag outer object 03030303...

good$ git tag -a outer # create a colliding tag good$ git remote add bad ../bad

good$ git remote update
warning: no common commits
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From ../bad
 * [new branch]      master     -> bad/master

Note how it has not fetched the tag ref, but it has fetched one of the tag objects:

$ git show 07070
error: Could not read object 0303030..
tag outer
Tagger: ...

$ git fsck ... dangling tag 07070...

I actually don't get that on the real repo, but do on this testcase. Hmm. `git fsck` exits with success here. This is bad, as the object graph is incomplete?

$ git gc fatal: bad object 03030303... error: failed to run repack

`git gc` fails with this meaningless error. The attached patch improves the error.

I don't know where the rest of the problem lies. What's the expected behaviour when a tag already exists locally, but is different? Fetch the object anyway, but ignore it?

From aa861789077012f78605431e1a1f191292693325 Mon Sep 17 00:00:00 2001
From: "Chris West (Faux)" <git@goeswhere.com>
Date: Fri, 19 May 2017 19:24:03 +0200
Subject: [PATCH] print tag id when tagged object is bad

---
 revision.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)