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?

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to