Chris Rorvick <chris@xxxxxxxxxxx> 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. -- 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