Re: [PATCH] l10n: vi.po: fix typo in pack-objects
Thank you for your patch. This typo probably is my false. On 10/25/18 2:01 AM, Minh Nguyen wrote: --- po/vi.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/po/vi.po b/po/vi.po index bc79319b6..e646825ed 100644 --- a/po/vi.po +++ b/po/vi.po @@ -13663,7 +13663,7 @@ msgstr "Đánh số các đối tượng" #: builtin/pack-objects.c:3382 #, c-format msgid "Total % (delta %), reused % (delta %)" -msgstr "Tỏng % (delta %), dùng lại % (delta %)" +msgstr "Tổng % (delta %), dùng lại % (delta %)" #: builtin/pack-refs.c:7 msgid "git pack-refs []" -- Trần Ngọc Quân.
Re: [GIT PULL] l10n updates for 2.10.0 round 2
On 31/08/2016 21:14, Jiang Xin wrote: > Hi Junio, > > Would you please pull the following git l10n updates. Please wait! Jiang Xin probably missing pull my one commit[1]. [1] <https://github.com/vnwildman/git/commit/800d88e2b3dde41ebf34e2e00955bba892419555> Thanks, -- Trần Ngọc Quân.
Re: Very Very small fonts in gitk
On 27/07/2016 15:05, jessie hernandez wrote:
> Dear git,
>
> I have been dealing with an issue in gitk for a while now. I do not
> know if this is a specific gitk issue or something else. I cannot find
> any information about it online.
>
> When I start gitk in my repository gitk comes up but all the font and
> all the menus are Extremly small. (see attached image).
>
> My OS is Red Hat 6.6
> git version is 2.0.3 (i tried the 2.9.2 version also and this too
> gives the same small font)
> I am running in bash also tried in KSH
>
> Could you give an insight if this is a known gitk issue or that this is a bug?
>
> Regards,
> Jessie Hernandez
Try to edit gitk configure file `~/.gitk` manually, like this:
set mainfont {{DejaVu Sans} 12}
set textfont {FreeMono 10}
set uifont {{DejaVu Sans} 12 bold}
I hope it work!
Thanks,
--
Trần Ngọc Quân.
--
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
Update Vietnamese translation for git-gui
Dear git-gui maintainers, Please pull the commit 1fa18b72184612e6615b1f119535183f40694fa4 from: https://github.com/vnwildman/git-gui.git on ``master'' branch. Thanks, -- Trần Ngọc Quân. -- 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
Re: How to repair a shallow clone (?)
On 06/12/2014 19:23, Torsten Bögershausen wrote: I think I started to clone the repo in a shallow way (SparkleShare asked if I want to clone the complete history, and I probably answered no ) Is there a way to repair this situation ? (Except doing a complete re-clone ?) I think git don't accept push from shallow repo. I've ever encounter this problem. I UNshallow it, then every thing will work: $ git fetch --unshallow origin This command will convert a shallow repository to a complete one. See git-fetch(1) and git-clone(1). I hope it helpful! Thanks, -- Trần Ngọc Quân. -- 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
Re: Found a bug in git 1.9.0 but can't reproduce it without copyrighted source code.
On 28/03/2014 07:45, yun sheng wrote: Hi, I found git sometimes can't detect working trees changes. But I can only reproduce this problem on several specific files, unfortunately these files are copyrighted source files so I can't send them to you. Is there anything I can do to narrow the problem and finally reproduce the bug without these commercial files? I posted a question on stackoverflow which shows the process. http://stackoverflow.com/questions/22684163/cant-reproduce-a-bug-in-git-without-a-specific-file Actually what I'm doing is: git init copy the first version of file into the working tree. git add . git commit -m 'init' copy and replace the file into working tree. git status and nothing is reported by git. these two files have the same timestamp, the same size, bug slightly different contents. These files were generated by `git difftool -d` I just manually copied them out from the temp directory just for future review. Don't worry about copyright, please run sha1sum in order to make sure the content is changed! Git I'm using is msysgit 1.9.0 on windows 7 Is it Ok on Linux OS, on other git version? Best regards, Sheng Yun -- -- Trần Ngọc Quân. -- 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
Re: [PATCH] l10n:gitk: Init Vietnamese translation
On 14/12/2013 09:42, Tran Ngoc Quan wrote: Signed-off-by: Tran Ngoc Quan vnwild...@gmail.com --- gitk-git/po/vi.po | 1350 + po/vi.po | 594 +++ Sorry, not include po/vi.po I Will sent other patch! -- Trần Ngọc Quân. -- 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
Re: problems with git --git-dir on windows 7
On 06/12/2013 08:07, Duy Nguyen wrote: On Wed, Dec 4, 2013 at 11:11 PM, SCHILZ MANFRED manfred.sch...@bgl.lu wrote: Hello, We are using git on windows7(git-version 1.8.1; see below) and we get the following problem in using the command 'git --git-dir=' C:\UserTemp\git\appli3git --git-dir=C:\UserTemp\git\appli3 tag fatal: Not a git repository: 'C:\UserTemp\git\appli3' but the repository is well defined,as we can run the following command: C:\UserTemp\git\appli3git log -1 --oneline 37cdbe0 Merge branch 'master' of L:/_ApplicationData/FBLU_IT-FLIT/se-DevelopSupp I have no clue. The --git-dir calls is_git_directory(C:\\UserTemp\\git\\appli3) while the git log calls is_git_directory(.). The former fails and the latter suceeds.. Copying msysgit@ maybe they know something. Btw what if you try git --git-dir=. tag in linux: $ git --git-dir=. tag fatal: Not a git repository: '.' ? You have to specify git dir instead of the dir contain .git This option use when your are not in git repo or git dir isn't .git as by default $ git --git-dir=.git tag $ git --git-dir=/mnt/E/MyProjects/git/.git tag $ git --version git version 1.8.5-rc1 When running the equivalent command on Linux, we don't have any problems: On Linux: git --git-dir=/tmp/GITPOC/appli3 tag V1.0 V1.1 V2.0 V3.0 Could you help me please ? Best regards Manfred Schilz --- C:\UserTemp\git\appli3git --version git version 1.8.1.msysgit.1 Internet communications are not secure and therefore BGL BNP Paribas does not accept legal responsibility for the contents of this message. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. -- 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 -- Trần Ngọc Quân. -- 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
Re: [PATCH v3] gettext.c: detect the vsnprintf bug at runtime
On 02/12/2013 14:40, Trần Ngọc Quân wrote:
On 02/12/2013 12:57, Duy Nguyen wrote:
I suggest use C preprocessor instead. The person who complete git (make
debian, rpm etc. package) decide enable it or not (disable by default).
Most of people use git from distribution instead of complete it from source.
#ifndef VSNPRINTF_OK
setlocale(LC_CTYPE, C);
#endif
A single vsnprintf is cheap enough that I would not worry about
performance impact. Given a choice between this and distro
maintainers, some of them do check release notes, some not so much,
I'd rather go with this.
We can set this macro automatically by using autoconf.
Add following code in configure.ac
AC_LANG_CONFTEST(
[AC_LANG_PROGRAM([[
#include stdio.h
#include locale.h
#include gnu/libc-version.h
#define STR David_K\345gedal
]],[[
char buf[20];
setlocale(LC_ALL, en_US.UTF-8);
if (snprintf(buf, 13, %.13s, STR) 0){
printf(0);
}else{
printf(1);
}
]])])
gcc -o conftest conftest.c
AC_DEFINE([VSNPRINTF_OK], [m4_esyscmd([./conftest])], [Enable l10n libc
if vnsprintf OK])
You can change c code here!
Sorry I'm wrong, m4_esyscmd don't work as I spect
Change to:
AC_LANG_CONFTEST(
[AC_LANG_PROGRAM([[
#include stdio.h
#include locale.h
#include gnu/libc-version.h
#define STR David_K\345gedal
]],[[
char buf[20];
setlocale(LC_CTYPE, en_US.UTF-8);
if (snprintf(buf, 13, %.13s, STR) 0){
printf(0);
}else{
printf(1);
}
]])])
gcc -o conftest conftest.c
VSNPRINTF=$(./conftest)
AC_DEFINE_UNQUOTED([VSNPRINTF_OK], [ $VSNPRINTF ], [Enable libc if
vnsprintf OK])
don't missing run this:
$ autoconf autoheader
My os (ubuntu 12.04) don't pass this test (libc6:i386 2.15-0ubuntu)
$ grep VSNPRINTF_OK config.h
#define VSNPRINTF_OK 0
--
Trần Ngọc Quân.
--
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
Re: [PATCH v3] gettext.c: detect the vsnprintf bug at runtime
On 01/12/2013 09:45, Nguyễn Thái Ngọc Duy wrote:
Bug 6530 [1] in glibc causes git show v0.99.6~1 to fail with error
your vsnprintf is broken. The workaround avoids that, but it
corrupts system error messages in non-C locales.
The bug has been fixed since 2.17. We could know running glibc version
with gnu_get_libc_version(). But version is not a sure way to detect
the bug because downstream may back port the fix to older versions. Do
a runtime test that immitates the call flow that leads to your
vsnprintf is broken. Only enable the workaround if the test fails.
Tested on Gentoo Linux, glibc 2.16.0 and 2.17, amd64.
[1] http://sourceware.org/bugzilla/show_bug.cgi?id=6530
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
v3 goes with runtime test instead of version check.
gettext.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/gettext.c b/gettext.c
index 71e9545..eed7c7f 100644
--- a/gettext.c
+++ b/gettext.c
@@ -29,6 +29,17 @@ int use_gettext_poison(void)
#endif
#ifndef NO_GETTEXT
+static int test_vsnprintf(const char *fmt, ...)
+{
+ char buf[26];
+ int ret;
+ va_list ap;
+ va_start(ap, fmt);
+ ret = vsnprintf(buf, sizeof(buf), fmt, ap);
+ va_end(ap);
+ return ret;
+}
+
this function alway run each time we run git commad while libc is
static. It is waste.
+ /* the string is taken from v0.99.6~1 */
+ if (test_vsnprintf(%.*s, 13, David_K\345gedal) 0)
+ setlocale(LC_CTYPE, C);
}
void git_setup_gettext(void)
I suggest use C preprocessor instead. The person who complete git (make debian,
rpm etc. package) decide enable it or not (disable by default). Most of people
use git from distribution instead of complete it from source.
#ifndef VSNPRINTF_OK
setlocale(LC_CTYPE, C);
#endif
--
Trần Ngọc Quân.
--
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
Re: [PATCH v3] gettext.c: detect the vsnprintf bug at runtime
On 02/12/2013 12:57, Duy Nguyen wrote:
I suggest use C preprocessor instead. The person who complete git (make
debian, rpm etc. package) decide enable it or not (disable by default).
Most of people use git from distribution instead of complete it from source.
#ifndef VSNPRINTF_OK
setlocale(LC_CTYPE, C);
#endif
A single vsnprintf is cheap enough that I would not worry about
performance impact. Given a choice between this and distro
maintainers, some of them do check release notes, some not so much,
I'd rather go with this.
We can set this macro automatically by using autoconf.
Add following code in configure.ac
AC_LANG_CONFTEST(
[AC_LANG_PROGRAM([[
#include stdio.h
#include locale.h
#include gnu/libc-version.h
#define STR David_K\345gedal
]],[[
char buf[20];
setlocale(LC_ALL, en_US.UTF-8);
if (snprintf(buf, 13, %.13s, STR) 0){
printf(0);
}else{
printf(1);
}
]])])
gcc -o conftest conftest.c
AC_DEFINE([VSNPRINTF_OK], [m4_esyscmd([./conftest])], [Enable l10n libc
if vnsprintf OK])
You can change c code here!
--
Trần Ngọc Quân.
--
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
Re: gettext CTYPE for libc
On 24/11/2013 16:05, Thomas Rast wrote: Trần Ngọc Quân vnwild...@gmail.com writes: $ git status fatal: Unable to read current working directory: Kh?ng c? t?p tin ho?c th? m?c nh? v?y So, somthing wrong with our charset. [...] Do you know why this suddenly broke? I think git set CTYPE=C for libc, so charset become 7-bit ASCII, but it don't set LC_MESSAGES=C for libc and libc will get this one from system variable. The long comment in init_gettext_charset() suggests that the *existing* code is there to handle exactly this problem, and apparently it doesn't. Why? Has libc moved the perror() strings into a separate domain in some version? See setlocale(3) [1] I'm a newbie in GIT. I'm not sure about git work correctly [2] if set git's charset to same with system. I don't think libc moved perror() string in separate domain. It use its own domain. [1] http://man7.org/linux/man-pages/man3/setlocale.3.html [2] incorrect if some function need work in ASCII mode -- Trần Ngọc Quân. -- 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
gettext CTYPE for libc
Hello, $ mkdir xyz $ cd xyz $ rmdir ../xyz $ git status fatal: Unable to read current working directory: Kh?ng c? t?p tin ho?c th? m?c nh? v?y So, somthing wrong with our charset. $ strace git status 21 | grep open open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3 open(/lib/i386-linux-gnu/libz.so.1, O_RDONLY|O_CLOEXEC) = 3 open(/lib/i386-linux-gnu/libcrypto.so.1.0.0, O_RDONLY|O_CLOEXEC) = 3 open(/lib/i386-linux-gnu/libpthread.so.0, O_RDONLY|O_CLOEXEC) = 3 open(/lib/i386-linux-gnu/libc.so.6, O_RDONLY|O_CLOEXEC) = 3 open(/lib/i386-linux-gnu/libdl.so.2, O_RDONLY|O_CLOEXEC) = 3 open(/dev/null, O_RDWR|O_LARGEFILE) = 3 open(/usr/lib/locale/locale-archive, O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 open(/usr/share/locale/locale.alias, O_RDONLY|O_CLOEXEC) = 3 open(/usr/share/locale/vi_VN/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/share/locale/vi/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/share/locale-langpack/vi_VN/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/share/locale-langpack/vi/LC_MESSAGES/libc.mo, O_RDONLY) = 3 open(/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache, O_RDONLY) = 3 We will see, this string come from libc.mo $ gettext --domain=libc No such file or directory Không có tập tin hoặc thư mục như vậy in git's gettext.c, it not allow CTYPE= for all domain, so we will set this one individually. In this ex. I set it for libc: $ git diff diff --git a/gettext.c b/gettext.c index 71e9545..abd3978 100644 --- a/gettext.c +++ b/gettext.c @@ -115,6 +115,7 @@ static void init_gettext_charset(const char *domain) setlocale(LC_CTYPE, ); charset = locale_charset(); bind_textdomain_codeset(domain, charset); + bind_textdomain_codeset(libc, charset); setlocale(LC_CTYPE, C); } And it work as I expect! -- Trần Ngọc Quân. -- 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
Re: [L10N] Kick off for Git 1.8.5 l10n round 1
On 02/11/2013 09:23, Jiang Xin wrote: 2013/11/2 Trần Ngọc Quân vnwild...@gmail.com: Strings in builtin/remote.c line 15 and 42 is similar, please change to same string in order to reduce gettext database (.mo file) -- Trần Ngọc Quân. Confirmed, there is a typo in builtin/remote.c line 15. Have you send patch to this list for this, Trần? This is minor error, so let Junio C Hamano do it! -- Trần Ngọc Quân. -- 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
RE: Please pull l10n updates for 1.8.1 round 1
Hello JX, You missing pull from my repo (2 commits instead of one, v1.7 and v1.8): dcc52a0449c7ee10690e23152e63b9798f8a332f $ git log -n 2 commit dcc52a0449c7ee10690e23152e63b9798f8a332f Author: Tran Ngoc Quan vnwild...@gmail.com Date: Sat Nov 24 07:37:35 2012 +0700 l10n: vi.po: Update follow git-v1.8.0-273-g2d242 Signed-off-by: Tran Ngoc Quan vnwild...@gmail.com commit 131fa518f10521b4a534863331decbfef2875f24 Author: Tran Ngoc Quan vnwild...@gmail.com Date: Wed Oct 31 08:19:59 2012 +0700 l10n: vi.po: update to git-v1.7.12-437-g1084f * updated all new messages (1967t0f0u) * make quote become more good-looking Signed-off-by: Tran Ngoc Quan vnwild...@gmail.com https://github.com/vnwildman/git.git master Thanks, Trần Ngọc Quân -Original Message- From: Jiang Xin [mailto:worldhello@gmail.com] Sent: Thursday, November 29, 2012 8:19 AM To: Junio C Hamano Cc: Git List; Peter Krefting; Trần Ngọc Quân; Nguyễn Thái Ngọc Duy Subject: Please pull l10n updates for 1.8.1 round 1 Hi, Junio The following changes since commit 2d242fb3fc19fc9ba046accdd9210be8b9913f64: Update draft release notes for 1.8.1 (2012-11-21 13:32:58 -0800) are available in the git repository at: git://github.com/git-l10n/git-po.git master for you to fetch changes up to 647d5183b8dc36b38d19c7a3f388108f245b11d3: l10n: Update Swedish translation (1975t0f0u) (2012-11-23 08:59:11 +0100) Jiang Xin (1): l10n: Update git.pot (14 new, 3 removed messages) Peter Krefting (1): l10n: Update Swedish translation (1975t0f0u) Tran Ngoc Quan (1): l10n: vi.po: update to git-v1.7.12-437-g1084f po/git.pot | 1224 -- po/sv.po | 1246 +-- po/vi.po | 1597 ++-- 3 files changed, 2097 insertions(+), 1970 deletions(-) -- Jiang Xin -- 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
