As far as I am concerned, I am pretty much done with this topic, at least for now. Of course if there are bugreports I'll try to help resolving them, but I do not expect myself adding new object-type based policy decision to this codepath.
The call the updated call makes to ref_newer() no longer feeds certain combinations to the function, because the NULL-ness of the old and commit-ness of both are checked before making a call. I notice that builtin/remote.c has another callsite for ref_newer(). Although I didn't look at the code, I think it is trying to see if the branch can be pushed as a fast-forward to the remote (or the remote tip moved since you started building on top of it). It probably makes sense to refactor the logic that is run per-ref in the loop in the set_ref_status_for_push() function into a new helper function, inline ref_newer() there, and have the remaining callers of ref_newer() to use that new helper function, which knows the new rules such as "refs/tags/ cannot be replaced with anything without force". -- 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
