push: clarify rejection of update to non-commit-ish
authorChris Rorvick <chris@rorvick.com>
Fri, 30 Nov 2012 01:41:39 +0000 (19:41 -0600)
committerJunio C Hamano <gitster@pobox.com>
Sun, 2 Dec 2012 09:45:13 +0000 (01:45 -0800)
commit80054cf9d53aad76631797d76ce33a56c855c61a
treee09b18a69c081bba660785c9f9ec19c5e6ec62fe
parent40eff1799983b958d6dbe09fb499ad505bcf6f8d
push: clarify rejection of update to non-commit-ish

Pushes must already (by default) update to a commit-ish due to the fast-
forward check in set_ref_status_for_push().  But rejecting for not being
a fast-forward suggests the situation can be resolved with a merge.
Flag these updates (i.e., to a blob or a tree) as not forwardable so the
user is presented with more appropriate advice.

While updating *from* a tag object is potentially destructive, updating
*to* a tag is not.  Additionally, a push to the refs/tags/ hierarchy is
already excluded from fast-forwarding, and refs/heads/ is protected from
anything but commit objects by a check in write_ref_sha1().  Thus
someone fast-forwarding to a tag is probably not doing so by accident.
Since updating to a tag is benign and unlikely to cause confusion, allow
it in case someone finds the behavior useful.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote.c