Gedare Bloom commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/288#note_115149 Yes, we should set this to 6.1 milestone to reduce the API breakage. Sebastian's argument that only the full hash exactly identifies the commit is valid. The short commit is a convenience only, and its length depends on the git repo being used to ensure uniqueness (no collisions), see https://git-scm.com/docs/git-show#Documentation/git-show.txt---abbrev-commit The short hash length can change if a collision occurs in the future within the current short hash length, which makes the short hash length unreliable. We can certainly revisit the discussion during 7.1, but given the unreliability of the short hash length, I don't see that we can use abbreviated commit hashes. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/288#note_115149 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
