From: "Torsten Bögershausen" <tboegi@web.de>
To: "Beat Bolli" <dev+git@drbeat.li>, "Torsten Bögershausen" <tboegi@web.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists
Date: Mon, 12 Dec 2016 19:12:38 +0100 [thread overview]
Message-ID: <ca10a51a-0fab-e4a4-8d7d-035673af4c06@web.de> (raw)
In-Reply-To: <c96d013c38df7737cfd551a0fce87314@drbeat.li>
>> 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.
next prev parent reply other threads:[~2016-12-12 18:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-11 23:34 [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists Beat Bolli
2016-12-11 23:34 ` [PATCH 2/3] update_unicode.sh: remove the plane filters Beat Bolli
2016-12-11 23:34 ` [PATCH 3/3] update_unicode.sh: restore hexadecimal output Beat Bolli
2016-12-12 5:53 ` [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists Torsten Bögershausen
2016-12-12 8:54 ` Beat Bolli
2016-12-12 18:12 ` Torsten Bögershausen [this message]
2016-12-12 18:33 ` Junio C Hamano
2016-12-12 23:50 ` Beat Bolli
2016-12-13 6:16 ` Torsten Bögershausen
2016-12-13 6:42 ` Junio C Hamano
2016-12-12 19:24 ` Beat Bolli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ca10a51a-0fab-e4a4-8d7d-035673af4c06@web.de \
--to=tboegi@web.de \
--cc=dev+git@drbeat.li \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).