Chris Rorvick <ch...@rorvick.com> writes:
> On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano <gits...@pobox.com> 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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html