From: Julian Phillips Date: Thu, 19 Apr 2007 08:49:42 GMT Subject: Re: [PATCH] refs.c: drop duplicate entries in sort_ref_list Message-ID: In-Reply-To: <4627262A.463AA87D@eudaptics.com> 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