Chris Rorvick <chris@xxxxxxxxxxx> writes: > On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> It is fine when pushing into "refs/tags/" hierarchy. It is *NOT* >> OK if the type check does not satisfy this function. In that case, >> we do not actually see the existence of the destination as a >> problem, but it is reported as such. We are blocking because we do >> not like the type of the new object or the type of the old object. >> If the destination points at a commit, the push can succeed if the >> user changes what object to push, so saying "you cannot push because >> the destination already exists" is just wrong in such a case. > > So the solution is to revert back to recommending a merge? Of course not, because at that point you may not even have what you were attempting to overwrite. Nobody says it is even something you could merge. The recommended solution certainly will involve a "fetch" (not "pull" or "pull --rebase"). You fetch from over there to check what you were about to overwrite, examine the situation to decide what the appropriate action is. The point is that Git in general, and the codepath that was touched by the patch in particular, does not have enough information to decide what the appropriate action is for the user, especially when the ref is outside the ones we know what the conventional uses of them are. We can make policy decisions like "tags are meant to be unmoving anchor points, so it is unusual to overwrite any old with any new", "heads are meant to be branch tips, and because rewinding them while more than one repositories are working with them will cause issues to other repositories, it is unusual to push a non-fast-forward" and enforcement mechanism for such policy decisions will help users, but that is only because we know what their uses are. The immediate action we should take is to get closer to the original behaviour of not complaining with "ref already exists", which is nonsensical. That does not mean that we will forbid improving the codepath by giving different advices depending on the case. One of the new advices could tell them to "fetch it and inspect the situation", if old is not something we do not even have (hence we cannot check its type, let alone the ancestry relationship of it with new), for example. -- 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