Julian Phillips wrote: > > It shouldn't happen that we read duplicate entries into the same list, > but just in case make sort_ref_list drop them. If the SHA1s don't > match then die instead, as we have no way of knowing which one is the > correct one. Clone a random repository that has tags, then $ rm .git/refs/tags/* $ git fetch origin now lists each tag twice: for the tag object itself and the commit it points to. Is this related to the problem you are solving here? If so, dying is probably not the best in this situation since the tags are still unique. (rm .git/refs/tags/* may be insane, but just the other day I wanted to clean up my repo from a number of unneeded branches as well as the tags that they contained - to find out that it is not enough to remove the refs: the objects must go away too, otherwise git fetch auto-follows them and the tags come back even though the branch heads are not there anymore.) $ git version git version 1.5.1.1.27.g91776 -- Hannes - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html