From: Junio C Hamano Date: Tue, 27 Nov 2012 17:11:44 GMT Subject: Re: [PATCH 7/7] push: clarify rejection of update to non-commit-ish Message-ID: <7vboejnf73.fsf@alter.siamese.dyndns.org> In-Reply-To: Chris Rorvick writes: >> With this code, the old must be a commit but new can be a tag that >> points at a commit? Why? > > The old must not be a tag because fast-forwarding from it is > potentially destructive; a tag would likely be left dangling in this > case. This is not true for the new, though. I'm not sure > fast-forwarding from a commit to a tag is useful, but I didn't see a > reason to prevent it either. The refs/tags/ hierarchy is excluded > from fast-forwarding before this check, and refs/heads/ is already > protected against anything but commits. So it seems very unlikely > that someone would accidentally make use of this behavior. > > So, fast-forwarding to a tag seemed fairly benign and unlikely to > cause confusion, so I leaned towards allowing it in case someone found > a use case for it. Sounds sensible. Perhaps some of that thinking behind this change (i.e. earlier we checked the forwardee was any commit-ish, but the new code only allows a commit object if it were to be fast-forwarded) belongs to the log message? Thanks.