Chris Rorvick <ch...@rorvick.com> 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.
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html