>> Minor question, especially to the next commit: >> Should we make sure to checkout the exact version, which has been tested? >> In this case cb97792880625e24a9f581412d03659091a0e54f >> >> And this is for both a fresh clone and the git pull >> needs to be replaced by >> git fetch && git checkout cb97792880625e24a9f581412d03659091a0e54f >> >> >> (Which of course is a shell variable) > > I was actually wondering what the policy was for adding submodules to the Git > repo, > but then decided against it. Another option would be to fork uniset on GitHub > and > just let it stay on a working commit. > > Junio, what's your stance on this? > > Beat
If I run ./update_unicode.sh on the latest master of https://github.com/depp/uniset.git , commit a5fac4a091857dd5429cc2d, I get a diff in unicode_width.h like this: -{ 0x0300, 0x036F }, +{ 768, 879 }, IOW, all hex values are printed as decimal values. Not a problem for the compiler, but for the human to check the unicode tables. So I think we should "pin" the version of uniset.
