* L10n for Git in Chinese begins
From: Jiang Xin @ 2012-01-30 8:21 UTC (permalink / raw)
To: Git List
With the release of v1.7.9 or some earlier , Git is multilingual.
I select some typical git commands and translated into Chinese,
both works.
- git status (in c)
- git stash (in bash)
Now I create a repo in Github hosting the po file (zh_cn.po) for git.
- repo: https://github.com/gotgit/git-l10n-zh-cn/
- file: https://github.com/gotgit/git-l10n-zh-cn/blob/master/zh_cn.po
Any help is appreciated, and will contribute here after 100% completed.
--
Jiang Xin
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Junio C Hamano @ 2012-01-30 8:22 UTC (permalink / raw)
To: Thomas Rast, Felipe Contreras; +Cc: Jonathan Nieder, git
In-Reply-To: <871uqh3a8s.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@inf.ethz.ch> wrote:
>Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> No reason. I hope they read the mailing list, otherwise I'll resend
>> and CC them. A get_maintainers script, or something like that would
>> make things easier.
>
>I simply use
>
> git shortlog -sn --no-merges v1.7.0.. -- contrib/completion/
>
>(In many parts the revision limiter can be omitted without losing much,
>but e.g. here this drops Shawn who hasn't worked on it since 2009.)
Or "--since=1.year", which you can keep using forever without adjusting.
^ permalink raw reply
* Re: [PATCH] completion: add new zsh completion
From: Matthieu Moy @ 2012-01-30 8:39 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1327881699-25461-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> +ZSH_VERSION='' . /usr/share/git/completion/git-completion.bash
Probably stating the obvious, but this path shouldn't be hardcoded.
Something along the lines of
ZSH_VERSION='' . $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
should do it (mostly untested, and written by a non-ZSH expert).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2012, #06; Fri, 27)
From: Matthieu Moy @ 2012-01-30 8:47 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <CAMP44s0FBm3_P--wykHRXROSQLFgmDeVwr2cyEgk33QBfYbdSA@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Sat, Jan 28, 2012 at 7:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> * mm/zsh-completion-regression-fix (2012-01-17) 1 commit
>>> (merged to 'next' on 2012-01-23 at 7bc2e0a)
>>> + bash-completion: don't add quoted space for ZSH (fix regression)
>>>
>>> Will merge early in the next cycle and deal with any fallout in 'master'.
>>
>> This topic has been superseded by Felipe's f15026b (git-completion:
>> workaround zsh COMPREPLY bug, 2012-01-25) to use "typeset -h IFS", so I
>> should drop this.
>>
>> Am I mistaken?
>
> That's correct.
Yes. You can drop my version.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* L10n for Git in Chinese begins
From: Jiang Xin @ 2012-01-30 8:55 UTC (permalink / raw)
To: Git List
With the release of v1.7.9 or some earlier , Git is multilingual.
I select some typical git commands and translated into Chinese,
works nice.
- git status (in c)
- git stash (in bash)
Now I create a repo in Github hosting the po file (zh_cn.po) for git.
- repo: https://github.com/gotgit/git-l10n-zh-cn/
- file: https://github.com/gotgit/git-l10n-zh-cn/blob/master/zh_cn.po
Any help is appreciated, and will contribute here after 100% completed.
--
Jiang Xin
^ permalink raw reply
* Re: gitweb showing slash r at the end of line
From: Jakub Narebski @ 2012-01-30 9:23 UTC (permalink / raw)
To: Ondra Medek; +Cc: git
In-Reply-To: <1327910140526-7235866.post@n2.nabble.com>
Ondra Medek <xmedeko@gmail.com> writes:
> I have read "SubmittingPatches". I have made a path by "git format-patch -M"
> and I have though it's enough. The problem maybe was, that I had not
> included "Subject: " from the result of "git format-patch -M". Next time I
> will try to do it better.
The problem is that in place of proper commit message, describing
change for posteriority as described in SubmittingPatches, you have an
email describing why you created this commit:
OM> Hi,
OM> we have gitweb running on Linux box. Some files have Windows line ending
OM> (CRLF) end we do not use core.autcrlf translation. gitweb show the last \r
OM> in the end of each line, which is annoying. I have creates a simple patch to
OM> avoid this. It adds just one line. I am not sure if the regexp should
OM> contain 'g' switch in the end. Also, not sure if there shoul be some config
OM> option to switch on/off this?
OM>
OM> Cheers
OM> Ondra
Take a look how other commit messages are written in git.git, and
please remember to sign off your patches.
> I am a Git newbie, but my bare repos have "config" file and this file can
> contain the "core.autocrlf" setting. So the gitweb can read it. Or what
> about to have a special section [gitweb] in this config? For now, the gitweb
> config files are somewhat "scattered" = "descrition", "cloneurl",
> "project.list", ...
The [gitweb] section contains stuff that can be used instead of
individual files like 'description' ('gitweb.description' can be used
instead if that file is not present), and also to configure
overridable features on per-repository basis, like 'gitweb.snapshot'.
> Yeah, the autodetection of mixed mode line endings could be the best
> solution.
>
> However, from my point of view a global gitweb setting would be enough for
> now.
I think that if not using autodetection this should be made into
proper gitweb %feature, e.g. named 'eol' - this automatically gives
ability to override it on per-repository basis via repo config.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH v4 1/2] gitweb: add project_filter to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-30 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7v7h0afcc2.fsf@alter.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [120129 22:06]:
> > @@ -2864,6 +2873,10 @@ sub git_get_projects_list {
> > }
> >
> > my $path = substr($File::Find::name, $pfxlen + 1);
> > + # paranoidly only filter here
> > + if ($paranoid && $filter && $path !~ m!^\Q$filter\E/!) {
> > + next;
> > + }
>
> When you find "foo" directory and a project_filter tells you to match
> "foo", because $path does not match "^foo/", it will not match (even
> though its subdirectory "foo/bar" would)?
Yes, for consistency with what would be shown with a project list file.
(And that it would only show projects which would have a link to this
directory in their breadcrumbs (with 2/2)).
> Perhaps that is the topic of your second patch. I dunno.
Yes, that is what the second patch does.
Bernhard R. Link
^ permalink raw reply
* Re: [PATCH 1/3] completion: be nicer with zsh
From: Felipe Contreras @ 2012-01-30 10:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4nvdeo23.fsf@alter.siamese.dyndns.org>
On Mon, Jan 30, 2012 at 7:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Avoiding zsh's bug that cannot use conditional assignment on the no-op
>> colon command (if the bug is really that; it is somewhat hard to imagine
>> if the bug exists only for colon command, though) *is* by itself a good
>> justification for this change, even though the resulting code is harder to
>> read for people who are used to read shell scripts.
>
> Just from my curiosity, I am wondering what zsh does when given these:
>
> bar () { echo "frotz nitfol xyzzy" }
>
> unset foo; : ${foo:=$(bar)}; echo "<$?,$foo>"
> unset foo; true ${foo:=$(bar)}; echo "<$?,$foo>"
> unset foo; echo >/dev/null ${foo:=$(bar)}; echo "<$?,$foo>"
<0,frotz nitfol xyzzy>
<0,frotz nitfol xyzzy>
<0,frotz nitfol xyzzy>
And that's _without_ bash emulation.
BTW. That code didn't work for me in bash (though it did in zsh), I
had to add a semicolon:
bar () { echo "frotz nitfol xyzzy" ;}
> The first one is exactly your "And yet another bug in zsh[1] causes a
> mismatch; zsh seems to have problem emulating wordspliting, but only when
> the ':' command is involved.", so we already know it "seems to have
> problem emulating word-splitting" (by the way, can we replace that with
> exact description of faulty symptom? e.g. "does not split words at $IFS"
> might be what you meant but still when we are assigning the result to a
> single variable, it is unclear how that matters).
That's not the problem, the problem is that this doesn't work in zsh:
array="a b c"
for i in $array; do
echo $i
done
The result is "a b c". Unless sh emulation is on. This is the correct
way in zsh:
array="a b c"
for i in ${=array}; do
echo $i
done
But this behavior can be controlled with SH_WORD_SPLIT.
Anyway, as I said, the problem is that the ':' have some problems, and
sh emulation seems to be turned off inside such command, or at least
SH_WORD_SPLIT was reset in my tests.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] completion: be nicer with zsh
From: Felipe Contreras @ 2012-01-30 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8vkperli.fsf@alter.siamese.dyndns.org>
On Mon, Jan 30, 2012 at 6:34 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Let's avoid it. This has the advantage that the code is now actually
>> understandable (at least to me), while before it looked like voodoo.
>
> I am somewhat hesitant to accept a patch to shell scripts on the basis
> that the patch author does not understand the existing constructs that
> are standard parts of shell idioms.
I have been writing shell scripts for years[1], and I have *never* had
an encounter with ':'. vim's sh syntax doesn't seem to be prepared for
it, and zsh's sh emulation has problems only when ':' is involved, so
I still think ':' is quite obscure.
Plus, I haven't seen ${foo:=bar} that often.
In any case, there's no need for ad hominem arguments; there is a
problem when using zsh, that's a fact.
[1] https://www.ohloh.net/accounts/felipec/positions/total
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Felipe Contreras @ 2012-01-30 10:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Jonathan Nieder, git
In-Reply-To: <25ea208e-353d-48f7-a849-143689fb2be6@email.android.com>
On Mon, Jan 30, 2012 at 10:22 AM, Junio C Hamano <jch2355@gmail.com> wrote:
> Thomas Rast <trast@inf.ethz.ch> wrote:
>>Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> No reason. I hope they read the mailing list, otherwise I'll resend
>>> and CC them. A get_maintainers script, or something like that would
>>> make things easier.
>>
>>I simply use
>>
>> git shortlog -sn --no-merges v1.7.0.. -- contrib/completion/
>>
>>(In many parts the revision limiter can be omitted without losing much,
>>but e.g. here this drops Shawn who hasn't worked on it since 2009.)
>
> Or "--since=1.year", which you can keep using forever without adjusting.
Perhaps something like that can be stored in a script somewhere in
git's codebase so that people can set sendemail.cccmd to that.
--
Felipe Contreras
^ permalink raw reply
* Re: L10n for Git in Chinese begins
From: Ævar Arnfjörð Bjarmason @ 2012-01-30 10:40 UTC (permalink / raw)
To: worldhello.net; +Cc: Git List
In-Reply-To: <4F265AEF.5020409@gmail.com>
2012/1/30 Jiang Xin <worldhello.net@gmail.com>:
> With the release of v1.7.9 or some earlier , Git is multilingual.
> I select some typical git commands and translated into Chinese,
> works nice.
>
> - git status (in c)
> - git stash (in bash)
>
> Now I create a repo in Github hosting the po file (zh_cn.po) for git.
>
> - repo: https://github.com/gotgit/git-l10n-zh-cn/
> - file: https://github.com/gotgit/git-l10n-zh-cn/blob/master/zh_cn.po
>
> Any help is appreciated, and will contribute here after 100% completed.
That's awesome, especially to get someone covering a really big
language whose speakers aren't usually near-native English speakers.
Please tell me if you have any problems, especially with the
instructions I added in po/README or anything else. I'd be happy to
fix them in Git if applicable.
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Felipe Contreras @ 2012-01-30 10:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vd3a1erwf.fsf@alter.siamese.dyndns.org>
On Mon, Jan 30, 2012 at 6:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> OK, maybe some people use it, but most likely they are using an old
>> version of git, and thus an old version of the completion script.
>
> Please adjust your attitude about backward compatibility to match the
> standard used for other parts of Git.
What attitude? I am simply stating a fact. How much percentage of
people do you think still have .git/remotes around? How many people do
you think have clones more than 3 years old? And how many of these
people would complain if remotes were not properly completed for these
repos?
I doubt anybody would have complained, but I guess we would never
know, because I already proposed a solution that would work for them
and only uses a *single* line of code, unlike the current 40 ones.
I don't see what is the problem with the attitude of sending a patch
to remove code that most likely nobody cares about (neither you or I
have numbers on this), and then finding an alternative when people do
care about it.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] use 'installsitelib' even with NO_PERL_MAKEMAKER
From: Nicholas Harteau @ 2012-01-30 10:51 UTC (permalink / raw)
To: git
perl/Makefile installs Git.pm into $prefix/lib when ExtUtils::MakeMaker
is not present. perl can't "use Git;" in that scenario, as $prefix/lib
isn't in perl's include path.
This patch installs Git.pm into perl's 'installsitelib', generally
$prefix/lib/perl5/site_perl, so that even when ExtUtils::MakeMaker isn't
present, Git.pm gets installed in a location where 'use Git;' just
works.
for some additional discussion, see:
https://github.com/mxcl/homebrew/pull/8643
https://github.com/mxcl/homebrew/issues/8620
---
perl/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/perl/Makefile b/perl/Makefile
index b2977cd..2199eb1 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -21,7 +21,7 @@ clean:
$(RM) $(makfile).old
ifdef NO_PERL_MAKEMAKER
-instdir_SQ = $(subst ','\'',$(prefix)/lib)
+instdir_SQ = $(subst ','\'',$(subst installsitelib=,'',$(shell $(PERL_PATH_SQ) -V:installsitelib)))
$(makfile): ../GIT-CFLAGS Makefile
echo all: private-Error.pm Git.pm > $@
echo ' mkdir -p blib/lib' >> $@
--
1.7.8.3
--
nicholas harteau
nrh@spotify.com
^ permalink raw reply related
* Re: [PATCH] completion: add new zsh completion
From: Felipe Contreras @ 2012-01-30 10:59 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqwr89d1p7.fsf@bauges.imag.fr>
On Mon, Jan 30, 2012 at 10:39 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> +ZSH_VERSION='' . /usr/share/git/completion/git-completion.bash
>
> Probably stating the obvious, but this path shouldn't be hardcoded.
>
> Something along the lines of
>
> ZSH_VERSION='' . $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>
> should do it (mostly untested, and written by a non-ZSH expert).
Yes, it's hard-coded, because there's no way to know where is this
file. In my case, it's on ~/.git-completion.sh, and this one that I am
proposing sits in ~/.zsh/completion/_zsh, so your proposal breaks
things completely for me.
I will think about it, but I think for now, users of this script
should set that manually--if for some reason they don't want to use
the default.
Maybe we should use zstyle so they can configure it on their .zshrc?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] completion: add new zsh completion
From: Johannes Sixt @ 2012-01-30 11:11 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Felipe Contreras, git
In-Reply-To: <vpqwr89d1p7.fsf@bauges.imag.fr>
Am 1/30/2012 9:39, schrieb Matthieu Moy:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> +ZSH_VERSION='' . /usr/share/git/completion/git-completion.bash
>
> Probably stating the obvious, but this path shouldn't be hardcoded.
>
> Something along the lines of
>
> ZSH_VERSION='' . $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>
> should do it (mostly untested, and written by a non-ZSH expert).
Moreover, if zsh is POSIX compliant, the value of ZSH_VERSION will be an
empty string after this statement. That may or (more likely) may not be
what you want.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Frans Klaver @ 2012-01-30 11:19 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <CAMP44s2j+qotu8Fb-1qq9bqHqt+ZF877YzZFXHiMo7Z_BGzTMA@mail.gmail.com>
Hi,
On Mon, Jan 30, 2012 at 11:51 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Jan 30, 2012 at 6:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> OK, maybe some people use it, but most likely they are using an old
>>> version of git, and thus an old version of the completion script.
>>
>> Please adjust your attitude about backward compatibility to match the
>> standard used for other parts of Git.
>
> What attitude?
This attitude:
> I am simply stating a fact. How much percentage of
> people do you think still have .git/remotes around? How many people do
> you think have clones more than 3 years old? And how many of these
> people would complain if remotes were not properly completed for these
> repos?
>
> I doubt anybody would have complained, but I guess we would never
> know, because I already proposed a solution that would work for them
> and only uses a *single* line of code, unlike the current 40 ones.
>
> I don't see what is the problem with the attitude of sending a patch
> to remove code that most likely nobody cares about (neither you or I
> have numbers on this), and then finding an alternative when people do
> care about it.
I don't think Junio actually meant an "attitude", but just your angle
of approach (== attitude) on backwards compatibility.
Maybe numbers for this could be generated from the next git user
survey. If numbers justify this change, maybe this or something like
it could be scheduled for a major release of git.
Cheers,
Frans
^ permalink raw reply
* [PATCH] find_pack_entry(): do not keep packed_git pointer locally
From: Nguyễn Thái Ngọc Duy @ 2012-01-30 11:25 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Commit f7c22cc (always start looking up objects in the last used pack
first - 2007-05-30) introduces a static packed_git* pointer as an
optimization. The kept pointer however may become invalid if
free_pack_by_name() happens to free that particular pack.
Current code base does not access packs after calling
free_pack_by_name() so it should not be a problem. Anyway, move the
pointer out so that free_pack_by_name() can reset it to avoid running
into troubles in future.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
sha1_file.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 88f2151..4ecc953 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -54,6 +54,8 @@ static struct cached_object empty_tree = {
0
};
+static struct packed_git *find_pack_entry_last_found = (void *)1;
+
static struct cached_object *find_cached_object(const unsigned char *sha1)
{
int i;
@@ -720,6 +722,8 @@ void free_pack_by_name(const char *pack_name)
close_pack_index(p);
free(p->bad_object_sha1);
*pp = p->next;
+ if (find_pack_entry_last_found == p)
+ find_pack_entry_last_found = (void*)1;
free(p);
return;
}
@@ -2012,14 +2016,13 @@ int is_pack_valid(struct packed_git *p)
static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)
{
- static struct packed_git *last_found = (void *)1;
struct packed_git *p;
off_t offset;
prepare_packed_git();
if (!packed_git)
return 0;
- p = (last_found == (void *)1) ? packed_git : last_found;
+ p = (find_pack_entry_last_found == (void *)1) ? packed_git : find_pack_entry_last_found;
do {
if (p->num_bad_objects) {
@@ -2046,16 +2049,16 @@ static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)
e->offset = offset;
e->p = p;
hashcpy(e->sha1, sha1);
- last_found = p;
+ find_pack_entry_last_found = p;
return 1;
}
next:
- if (p == last_found)
+ if (p == find_pack_entry_last_found)
p = packed_git;
else
p = p->next;
- if (p == last_found)
+ if (p == find_pack_entry_last_found)
p = p->next;
} while (p);
return 0;
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Re: [PATCH] completion: add new zsh completion
From: Felipe Contreras @ 2012-01-30 11:28 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <CAMP44s3QeZuXrR=UE4qvDadu66Cmi-txmSps8Ow24om27URxOg@mail.gmail.com>
On Mon, Jan 30, 2012 at 12:59 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Jan 30, 2012 at 10:39 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> +ZSH_VERSION='' . /usr/share/git/completion/git-completion.bash
>>
>> Probably stating the obvious, but this path shouldn't be hardcoded.
>>
>> Something along the lines of
>>
>> ZSH_VERSION='' . $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>>
>> should do it (mostly untested, and written by a non-ZSH expert).
>
> Yes, it's hard-coded, because there's no way to know where is this
> file. In my case, it's on ~/.git-completion.sh, and this one that I am
> proposing sits in ~/.zsh/completion/_zsh, so your proposal breaks
> things completely for me.
>
> I will think about it, but I think for now, users of this script
> should set that manually--if for some reason they don't want to use
> the default.
>
> Maybe we should use zstyle so they can configure it on their .zshrc?
This seems to do the trick:
zstyle -s ":completion:$curcontext:" script script
test -z "$script" && script="$(dirname
${funcsourcetrace[1]%:*})"/git-completion.bash
ZSH_VERSION='' . "$script"
.zshrc:
zstyle ':completion:*:*:git:*' script ~/.git-completion.sh
--
Felipe Contreras
^ permalink raw reply
* i18n: Avoid sentence puzzles
From: Frederik Schwarzer @ 2012-01-30 11:31 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]
Hi,
in order to enable translators to prepare proper translations,
sentence puzzles have to be avoided. While it makes perfect sense for
English, some languages may have to separate those words to sound or
even be correct.
The attached patch demonstrates a change to achive that. I did not
test it because its purpose is only to raise awareness and start a
discussion about this topic. After all the question is, how important
translations are for a tool like Git. I have started a German
translation but many things are really hard to translate.
1) Many words are used in a germanised way, so translating them
not only feels awkward in some cases but it also might confuse
users who are used to the original wording.
2) English is a language that can be used in a very compact way.
In German that can feel dumb or even rude. So texts can grow
up to twice or thrice their size. That can clutter the terminal
appearance quite a bit.
Given those problems many people avoid using command line tools in
their language and I see the usefulness of translations rather
limited.
So my question would be: Is it considered worth it to extend the code
for translators' and translations' sake? If so, I would be glad to
help with that.
Regards
[-- Attachment #2: 0001-Avoid-puzzle-sentences.patch --]
[-- Type: text/x-patch, Size: 2440 bytes --]
From 7b1475cbffe120fdae1b46a2974a7b94846702c4 Mon Sep 17 00:00:00 2001
From: Frederik Schwarzer <schwarzerf@gmail.com>
Date: Mon, 30 Jan 2012 12:02:46 +0100
Subject: [PATCH] Avoid puzzle sentences.
---
builtin/branch.c | 27 ++++++++++++++++++---------
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 7095718..a07ac54 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -154,18 +154,17 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
const char *fmt, *remote;
int i;
int ret = 0;
+ int is_remote = 0;
struct strbuf bname = STRBUF_INIT;
switch (kinds) {
case REF_REMOTE_BRANCH:
fmt = "refs/remotes/%s";
- /* TRANSLATORS: This is "remote " in "remote branch '%s' not found" */
- remote = _("remote ");
+ is_remote = 1;
force = 1;
break;
case REF_LOCAL_BRANCH:
fmt = "refs/heads/%s";
- remote = "";
break;
default:
die(_("cannot use -a with -d"));
@@ -189,8 +188,11 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
name = xstrdup(mkpath(fmt, bname.buf));
if (read_ref(name, sha1)) {
- error(_("%sbranch '%s' not found."),
- remote, bname.buf);
+ if (is_remote) {
+ error(_("remote branch '%s' not found."), bname.buf);
+ } else {
+ error(_("branch '%s' not found."), bname.buf);
+ }
ret = 1;
continue;
}
@@ -211,14 +213,21 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
}
if (delete_ref(name, sha1, 0)) {
- error(_("Error deleting %sbranch '%s'"), remote,
- bname.buf);
+ if (is_remote) {
+ error(_("Error deleting remote branch '%s'"), bname.buf);
+ } else {
+ error(_("Error deleting branch '%s'"), bname.buf);
+ }
ret = 1;
} else {
struct strbuf buf = STRBUF_INIT;
- printf(_("Deleted %sbranch %s (was %s).\n"), remote,
- bname.buf,
+ if (is_remote) {
+ printf(_("Deleted remote branch %s (was %s).\n"), bname.buf,
find_unique_abbrev(sha1, DEFAULT_ABBREV));
+ } else {
+ printf(_("Deleted branch %s (was %s).\n"), bname.buf,
+ find_unique_abbrev(sha1, DEFAULT_ABBREV));
+ }
strbuf_addf(&buf, "branch.%s", bname.buf);
if (git_config_rename_section(buf.buf, NULL) < 0)
warning(_("Update of config-file failed"));
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH] completion: add new zsh completion
From: Felipe Contreras @ 2012-01-30 11:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Matthieu Moy, git
In-Reply-To: <4F267AC9.1080407@viscovery.net>
On Mon, Jan 30, 2012 at 1:11 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 1/30/2012 9:39, schrieb Matthieu Moy:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> +ZSH_VERSION='' . /usr/share/git/completion/git-completion.bash
>>
>> Probably stating the obvious, but this path shouldn't be hardcoded.
>>
>> Something along the lines of
>>
>> ZSH_VERSION='' . $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>>
>> should do it (mostly untested, and written by a non-ZSH expert).
>
> Moreover, if zsh is POSIX compliant, the value of ZSH_VERSION will be an
> empty string after this statement. That may or (more likely) may not be
> what you want.
It's not, only inside that script. Same in bash.
And that's exactly what I want... I wan the git-completion.bash to
avoid any zsh hacks and workarounds.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH v5 1/5] gitweb: prepare git_get_projects_list for use outside 'forks'.
From: Bernhard R. Link @ 2012-01-30 11:44 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git
In-Reply-To: <20120130095252.GA6183@server.brlink.eu>
Use of the filter option of git_get_projects_list is currently
limited to forks. It hard codes removal of ".git" suffixes from
the filter and assumes the project belonging to the filter directory
was already validated to be visible in the project list.
To make it more generic move the .git suffix removal to the callers
and add an optional argument to denote visibility verification is
still needed.
If there is a projects list file (GITWEB_LIST) only projects from
this list are returned anyway, so no more checks needed.
If there is no projects list file and the caller requests strict
checking (GITWEB_STRICT_EXPORT), do not jump directly to the
given directory but instead do a normal search and filter the
results instead.
The only (hopefully non-existing) effect of GITWEB_STRICT_EXPORT
without GITWEB_LIST is to make sure no project can be viewed without
also be found starting from project root. git_get_projects_list without
this patch does not enforce this but all callers only call it with
a filter already checked this way. With this parameter a caller
can request this check if the filter cannot be checked this way.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Changes to v4:
- split patch in smaller parts
- move ".git" suffix removal from filters to forks specific code
(if you want this as patch on top of the previous series, let me know)
- improve the descriptions of all patches
---
gitweb/gitweb.perl | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9cf7e71..acf1bae 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2829,10 +2829,9 @@ sub git_get_project_url_list {
sub git_get_projects_list {
my $filter = shift || '';
+ my $paranoid = shift;
my @list;
- $filter =~ s/\.git$//;
-
if (-d $projects_list) {
# search in directory
my $dir = $projects_list;
@@ -2841,7 +2840,7 @@ sub git_get_projects_list {
my $pfxlen = length("$dir");
my $pfxdepth = ($dir =~ tr!/!!);
# when filtering, search only given subdirectory
- if ($filter) {
+ if ($filter and not $paranoid) {
$dir .= "/$filter";
$dir =~ s!/+$!!;
}
@@ -2866,6 +2865,10 @@ sub git_get_projects_list {
}
my $path = substr($File::Find::name, $pfxlen + 1);
+ # paranoidly only filter here
+ if ($paranoid && $filter && $path !~ m!^\Q$filter\E/!) {
+ next;
+ }
# we check related file in $projectroot
if (check_export_ok("$projectroot/$path")) {
push @list, { path => $path };
@@ -6007,7 +6010,7 @@ sub git_forks {
die_error(400, "Unknown order parameter");
}
- my @list = git_get_projects_list($project);
+ my @list = git_get_projects_list($project =~ s/\.git$//r);
if (!@list) {
die_error(404, "No forks found");
}
@@ -6066,7 +6069,7 @@ sub git_summary {
if ($check_forks) {
# find forks of a project
- @forklist = git_get_projects_list($project);
+ @forklist = git_get_projects_list($project =~ s/\.git$//r);
# filter out forks of forks
@forklist = filter_forks_from_projects_list(\@forklist)
if (@forklist);
--
1.7.8.3
^ permalink raw reply related
* [PATCH v5 2/5] gitweb: add project_filter to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-30 11:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <20120130095252.GA6183@server.brlink.eu>
This commit changes the project listing views (project_list,
project_index and opml) to limit the output to only projects in a
subdirectory if the new optional parameter ?pf=directory name is
used.
The implementation of the filter reuses the implementation used for
the 'forks' action (i.e. listing all projects within that directory
from the projects list file (GITWEB_LIST) or only projects in the
given subdirectory of the project root directory without a projects
list file).
Reusing $project instead of adding a new parameter would have been
nicer from a UI point-of-view (including PATH_INFO support) but
would complicate the $project validating code that is currently
being used to ensure nothing is exported that should not be viewable.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
gitweb/gitweb.perl | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index acf1bae..36efc10 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -760,6 +760,7 @@ our @cgi_param_mapping = (
search_use_regexp => "sr",
ctag => "by_tag",
diff_style => "ds",
+ project_filter => "pf",
# this must be last entry (for manipulation from JavaScript)
javascript => "js"
);
@@ -976,7 +977,7 @@ sub evaluate_path_info {
our ($action, $project, $file_name, $file_parent, $hash, $hash_parent, $hash_base,
$hash_parent_base, @extra_options, $page, $searchtype, $search_use_regexp,
- $searchtext, $search_regexp);
+ $searchtext, $search_regexp, $project_filter);
sub evaluate_and_validate_params {
our $action = $input_params{'action'};
if (defined $action) {
@@ -994,6 +995,13 @@ sub evaluate_and_validate_params {
}
}
+ our $project_filter = $input_params{'project_filter'};
+ if (defined $project_filter) {
+ if (!validate_pathname($project_filter)) {
+ die_error(404, "Invalid project_filter parameter");
+ }
+ }
+
our $file_name = $input_params{'file_name'};
if (defined $file_name) {
if (!validate_pathname($file_name)) {
@@ -5984,7 +5992,7 @@ sub git_project_list {
die_error(400, "Unknown order parameter");
}
- my @list = git_get_projects_list();
+ my @list = git_get_projects_list($project_filter, $strict_export);
if (!@list) {
die_error(404, "No projects found");
}
@@ -6023,7 +6031,7 @@ sub git_forks {
}
sub git_project_index {
- my @projects = git_get_projects_list();
+ my @projects = git_get_projects_list($project_filter, $strict_export);
if (!@projects) {
die_error(404, "No projects found");
}
@@ -7860,7 +7868,7 @@ sub git_atom {
}
sub git_opml {
- my @list = git_get_projects_list();
+ my @list = git_get_projects_list($project_filter, $strict_export);
if (!@list) {
die_error(404, "No projects found");
}
--
1.7.8.3
^ permalink raw reply related
* [PATCH 3/5] gitweb: limit links to alternate forms of project_list to active project_filter
From: Bernhard R. Link @ 2012-01-30 11:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <20120130095252.GA6183@server.brlink.eu>
If project_list action is given a project_filter argument, pass that to
TXT and OPML formats.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
gitweb/gitweb.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 36efc10..e022e11 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3976,9 +3976,11 @@ sub git_footer_html {
}
} else {
- print $cgi->a({-href => href(project=>undef, action=>"opml"),
+ print $cgi->a({-href => href(project=>undef, action=>"opml",
+ project_filter => $project_filter),
-class => $feed_class}, "OPML") . " ";
- print $cgi->a({-href => href(project=>undef, action=>"project_index"),
+ print $cgi->a({-href => href(project=>undef, action=>"project_index",
+ project_filter => $project_filter),
-class => $feed_class}, "TXT") . "\n";
}
print "</div>\n"; # class="page_footer"
--
1.7.8.3
^ permalink raw reply related
* Re: i18n: Avoid sentence puzzles
From: Nguyen Thai Ngoc Duy @ 2012-01-30 11:46 UTC (permalink / raw)
To: Frederik Schwarzer; +Cc: git
In-Reply-To: <201201301231.21090.schwarzerf@gmail.com>
On Mon, Jan 30, 2012 at 6:31 PM, Frederik Schwarzer
<schwarzerf@gmail.com> wrote:
> Hi,
>
> in order to enable translators to prepare proper translations,
> sentence puzzles have to be avoided. While it makes perfect sense for
> English, some languages may have to separate those words to sound or
> even be correct.
>
> The attached patch demonstrates a change to achive that.
> ...
> So my question would be: Is it considered worth it to extend the code
> for translators' and translations' sake? If so, I would be glad to
> help with that.
As a translator (though not git's because my time is limited and GUI
apps have my priority), I completely agree and support this. There are
other places where a sentence is broken down into many short phrases.
It's hard for a translator to find a good translation in such cases.
I remember there was also a patch about "1 file vs 2 files" in diff
summary, which was rejected because it would break scripts. I think
grammar patches should be allowed at least for interactive use (i.e.
either pager is on, or std{out,err} is tty).
--
Duy
^ permalink raw reply
* [PATCH v5 4/5] gitweb: show active project_filter in project_list page header
From: Bernhard R. Link @ 2012-01-30 11:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <20120130095252.GA6183@server.brlink.eu>
In a project_list view show breadcrumbs with the currently active
project_filter (and those of parent directories) in the page header.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
gitweb/gitweb.perl | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e022e11..dfc79df 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3836,6 +3836,18 @@ sub print_header_links {
}
}
+sub print_nav_breadcrumbs_path {
+ my $dirprefix = undef;
+ while (my $part = shift) {
+ $dirprefix .= "/" if defined $dirprefix;
+ $dirprefix .= $part;
+ print $cgi->a({-href => href(project => undef,
+ project_filter => $dirprefix,
+ action=>"project_list")},
+ esc_html($part)) . " / ";
+ }
+}
+
sub print_nav_breadcrumbs {
my %opts = @_;
@@ -3854,6 +3866,8 @@ sub print_nav_breadcrumbs {
print " / $opts{-action_extra}";
}
print "\n";
+ } elsif (defined $project_filter) {
+ print_nav_breadcrumbs_path(split '/', $project_filter);
}
}
--
1.7.8.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox