This builds on Chris Rorvick's earlier effort to forbid unforced updates to refs/tags/ hierarchy and giving sensible error and advise messages for that case (we are not rejecting such a push due to fast forwardness, and suggesting to fetch and integrate before pushing again does not make sense). The series applies on top of 256b9d7 (push: fix "refs/tags/ hierarchy cannot be updated without --force", 2013-01-16). The main change is in the second patch. When we * do not have the object at the tip of the remote; * the object at the tip of the remote is not a commit; or * the object we are pushing is not a commit, there is no point suggesting to fetch, integrate and push again. If we do not have the current object at the tip of the remote, we should tell the user to fetch first and evaluate the situation before deciding what to do next. Otherwise, if the current object is not a commit, or if we are trying to push an object that is not a commit, then the user does not have to fetch first (we already have the object), but it still does not make sense to suggest to integrate and re-push. Just tell them that such a push requires a force in such a case. Junio C Hamano (3): push: further clean up fields of "struct ref" push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE push: further simplify the logic to assign rejection status advice.c | 4 ++++ advice.h | 2 ++ builtin/push.c | 25 +++++++++++++++++++++++++ builtin/send-pack.c | 10 ++++++++++ cache.h | 6 +++--- remote.c | 42 +++++++++++++++++++----------------------- send-pack.c | 2 ++ transport-helper.c | 10 ++++++++++ transport.c | 14 +++++++++++++- transport.h | 2 ++ 10 files changed, 90 insertions(+), 27 deletions(-) -- 1.8.1.1.498.gfdee8be -- 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