On Thu, 19 Apr 2007, Johannes Sixt wrote:
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.
The sort function is only looking at refs. So if you rm .git/refs/tags/*
then you don't have any tag refs (assuming no packed-refs). What it is
talking about is having two instances of (e.g.) refs/tags/foo.
In the situation you mention above you still shouldn't see duplicated
refs.
--
Julian
---
Ah, so that's what's been wrong with the little fella. He misses
casual sex.
-- Homer Simpson
Two Dozen and One Greyhounds
-
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