Jiang Xin writes:
> Scan the whole rfc2822 footer for duplicate S-o-b, not just the last
> line of the commit message.
>
> A commit may have multiple S-o-bs, or other tags, such as:
>
> some commit log...
>
> Signed-off-by: C O Mitter
> Reported-by: R E Porter
>
> Because the S-o-b
Test "t/t7502-commit.sh" failed. I guess it's commit
v1.7.9.7-1-gf20f387 which breaks it.
$ git log -1 --oneline --stat v1.7.9.7-1-gf20f387
f20f commit: check committer identity more strictly
builtin/commit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Result of t/t7502
Keep the temporary directory around when compare()
cannot read its input files, which is indicated by -1.
Defer tempdir creation to allow an early exit in setup_dir_diff().
Wrap the rest of the entry points in an exit_cleanup() function
to handle removing temporary files and error reporting.
Prin
Keep everything within 80 columns. Wrap the user-facing messages too.
Signed-off-by: David Aguilar
---
The only remaining long lines were touched in 2/2.
git-difftool.perl | 46 --
1 file changed, 32 insertions(+), 14 deletions(-)
diff --git a/git-d
Scan the whole rfc2822 footer for duplicate S-o-b, not just the last
line of the commit message.
A commit may have multiple S-o-bs, or other tags, such as:
some commit log...
Signed-off-by: C O Mitter
Reported-by: R E Porter
Because the S-o-b is not located at the last line in the
Michael G Schwern wrote:
> On 2012.7.25 4:48 PM, Eric Wong wrote:
> > We need to use something. Right now our choice of mailer is the best
> > choice for _existing_ contributors.
>
> I believe this entire discussion can be reduced to that right there.
>
> If your process is optimized for existi
Michael G Schwern wrote:
>Do we care about getting new contributors?
Not if the cost is too high, no. I personally do think it is
important to make life easy for new contributors, not because that
will somehow compel them to work for me for free, but because it's
On 2012.7.25 4:48 PM, Eric Wong wrote:
> We need to use something. Right now our choice of mailer is the best
> choice for _existing_ contributors.
I believe this entire discussion can be reduced to that right there.
If your process is optimized for existing contributors, it will work well for
e
Michael G Schwern wrote:
> This is rapidly getting into the weeds. Regardless of the debate below, what
> would you like me to do? Switch indentation to tabs and resubmit? AFAIK only
> the new tests are affected.
Yes, please do so at some point before the final submission. (If
there's more fe
Michael G Schwern wrote:
> This is rapidly getting into the weeds. Regardless of the debate below, what
> would you like me to do? Switch indentation to tabs and resubmit? AFAIK only
> the new tests are affected.
Yes, unless Jonathan (or anybody else) has more comments.
> On 2012.7.25 4:08 PM
This is rapidly getting into the weeds. Regardless of the debate below, what
would you like me to do? Switch indentation to tabs and resubmit? AFAIK only
the new tests are affected.
On 2012.7.25 4:08 PM, Eric Wong wrote:
+BEGIN {
+# Override exit at BEGIN time before Git::SVN::Ut
Michael G Schwern wrote:
> On 2012.7.24 7:55 PM, Eric Wong wrote:
> > Except git is also a "new specialized tool". Your examples are exactly
> > why I'm saddened many projects only adopted git, but not the workflow
> > which _built_ git (and Linux).
>
> Github also has broad spectrum utility. I
Junio C Hamano wrote:
> Michael G Schwern writes:
> > So... is that master or maint? Just let me know which one.
>
> I do not care too deeply either way, and in the end I think Eric
> should have the final say.
>
> Given that git://git.bogomips.org/git-svn.git/ has 'master' but
> nothing to bu
Michael G Schwern writes:
> On 2012.7.25 3:19 PM, Junio C Hamano wrote:
>> Michael G Schwern writes:
>>> How about the git-svn SVN 1.7 fix in general? All of these patch sets I'm
>>> sending build on one another, is that going to be a problem? It's going to
>>> come in about six parts.
>>
>>
Michael G Schwern wrote:
> On 2012.7.25 2:24 PM, Eric Wong wrote:
> > Didn't we agree to use done_testing()? Perhaps (as you suggested) with
> > a private copy of Test::More? It's probably easier to start using
> > done_testing() earlier rather than later.
>
> Yes, we agreed done_testing is th
On 2012.7.25 3:19 PM, Junio C Hamano wrote:
> Michael G Schwern writes:
>> How about the git-svn SVN 1.7 fix in general? All of these patch sets I'm
>> sending build on one another, is that going to be a problem? It's going to
>> come in about six parts.
>
> Judging from the rate of the discuss
On 2012.7.25 2:24 PM, Eric Wong wrote:
> Please keep Jonathan Cc:-ed, he's been very helpful with this series
> (and very helpful in general :)
I will try.
>> +use Test::More 'no_plan';
>
> Didn't we agree to use done_testing()? Perhaps (as you suggested) with
> a private copy of Test::More?
On Wed, Jul 25, 2012 at 03:05:42PM -0700, Junio C Hamano wrote:
> > I've just been hunting the same bug and came up with the same answer.
> > Here's a commit message. Feel free to apply or steal text for your
> > commit.
>
> Heh, let's try not to waste duplicated efforts by being silent next
> ti
Michael G Schwern writes:
>>> Also I just realized I've been basing my work on master. Should I move to
>>> maint?
>>
>> I don't think so. It is not fixing any urgent breakage (iow, by
>> being told about .pm explicitly, it knows about them just fine
>> without being taught how to find them).
Jens Lehmann writes:
> Am 25.07.2012 20:44, schrieb Junio C Hamano:
>> Stefan Zager writes:
>>
>>> Currently, it will only do a checkout if the sha1 registered in the
>>> containing
>>> repository doesn't match the HEAD of the submodule, regardless of whether
>>> the
>>> submodule is dirty.
Jonathan Nieder writes:
> FWIW I find Junio's test_setup name more self-explanatory. What
> mnemonic should I be using to remember the _fixture name?
Previous exposure to things like Rails?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@v
Jeff King writes:
> On Wed, Jul 25, 2012 at 02:52:54PM -0700, Junio C Hamano wrote:
>
>> Paul Gortmaker writes:
>>
>> > Has anyone else noticed false positives coming from the
>> > orphan check?
>>
>> Thanks. This should fix it.
>
> I've just been hunting the same bug and came up with the sam
On Wed, Jul 25, 2012 at 02:52:54PM -0700, Junio C Hamano wrote:
> Paul Gortmaker writes:
>
> > Has anyone else noticed false positives coming from the
> > orphan check?
>
> Thanks. This should fix it.
I've just been hunting the same bug and came up with the same answer.
Here's a commit messag
On 2012.7.25 2:15 PM, Jonathan Nieder wrote:
> Michael G. Schwern wrote:
>> This is a refactoring to move Git::SVN out of git-svn and into its own .pm
>> file.
>> This will make it easier to work with and test. This is just the extraction
>> with minimal work to keep all tests passing.
>
> Patch
Michael G Schwern wrote:
> On 2012.7.25 2:11 PM, Jonathan Nieder wrote:
>> Who are these comments in perl/Makefile.PL addressed to?
>
> Somebody adding, renaming or deleting a .pm file.
>
>> Why would such a person be looking at perl/Makefile.PL?
>
> Because sometimes they do wacky things
Not con
Paul Gortmaker writes:
> Has anyone else noticed false positives coming from the
> orphan check?
Thanks. This should fix it.
builtin/checkout.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 6acca75..d812219 100644
--- a/built
On 2012.7.25 2:11 PM, Jonathan Nieder wrote:
>> --- a/perl/Makefile.PL
>> +++ b/perl/Makefile.PL
>> @@ -2,6 +2,10 @@ use strict;
>> use warnings;
>> use ExtUtils::MakeMaker;
>> use Getopt::Long;
>> +use File::Find;
>> +
>> +# Don't forget to update the perl/Makefile, too.
>> +# Don't forget to t
Jonathan Nieder wrote:
> Michael G. Schwern wrote:
>> --- a/perl/Makefile.PL
>> +++ b/perl/Makefile.PL
>> @@ -2,6 +2,10 @@ use strict;
>> use warnings;
>> use ExtUtils::MakeMaker;
>> use Getopt::Long;
>> +use File::Find;
>> +
>> +# Don't forget to update the perl/Makefile, too.
>> +# Don't forg
"Michael G. Schwern" wrote:
> From: "Michael G. Schwern"
>
> Put them in a new module called Git::SVN::Utils. Yeah, not terribly
> original and it will be a dumping ground. But its better than having
> them in the main git-svn program. At least they can be documented
> and tested.
>
> * fata
Hi,
Michael G. Schwern wrote:
> This is a refactoring to move Git::SVN out of git-svn and into its own .pm
> file.
> This will make it easier to work with and test. This is just the extraction
> with minimal work to keep all tests passing.
Patch 3 doesn't seem to have hit the list archive. I
On 2012.7.25 1:32 PM, Junio C Hamano wrote:
> Michael G Schwern writes:
>
>> What's the lag time on it showing up in the repo, and which branch will it
>> appear in?
>
> There is nothing special in this topic, so it is likely to start on
> 'pu', and unlikely to come to 'master' before 1.7.12 shi
Hi,
Michael G. Schwern wrote:
> It is no longer necessary to manually add new .pm files to the
> Makefile.PL. This makes it easier to add modules.
Thanks! Sorry I missed this.
[...]
> --- a/perl/Makefile.PL
> +++ b/perl/Makefile.PL
> @@ -2,6 +2,10 @@ use strict;
> use warnings;
> use ExtUti
Am 25.07.2012 20:44, schrieb Junio C Hamano:
> Stefan Zager writes:
>
>> Currently, it will only do a checkout if the sha1 registered in the
>> containing
>> repository doesn't match the HEAD of the submodule, regardless of whether the
>> submodule is dirty. As discussed on the mailing list, th
Hi,
Ramsay Jones wrote:
> Junio C Hamano wrote:
>> Observing that all well-written test scripts we have begin with this
>> boilerplate line:
>>
>> test_expect_success setup '
>>
>> I wouldn't mind introducing a new helper function test_setup that
>> behaves like test_expect_success but is me
Torsten Bögershausen skrev 2012-06-24 17.47:
Do we have a motivation for pushing a solution that ignores
the unicode composition ?
I say we do. I tried your patch and it worked fine.
I'll send a V5 version with hopefully a better motivation
-- robin
--
To unsubscribe from this list: send
On Wed, Jul 25, 2012 at 2:53 PM, Paul Gortmaker
wrote:
> Has anyone else noticed false positives coming from the
> orphan check? It is warning me about commits that are
> clearly on master. Here is an example, where I checkout
> master~2 and then switch back to master. It somehow thinks
> that
Michael G Schwern writes:
> What's the lag time on it showing up in the repo, and which branch will it
> appear in?
There is nothing special in this topic, so it is likely to start on
'pu', and unlikely to come to 'master' before 1.7.12 ships sometime
next month.
> Also I just realized I've bee
On 2012.7.25 9:56 AM, Junio C Hamano wrote:
> Looks sensible. Will queue.
>
> Thanks.
Thanks!
What's the lag time on it showing up in the repo, and which branch will it
appear in?
Also I just realized I've been basing my work on master. Should I move to
maint?
--
If you want the truth to
Jonathan Nieder wrote:
>> This version of the patch only moves code to determine the test
>> prerequisite to the outer level, while leaving the 'setup' aspects
>> of the first test in place.
>
> I guess I don't see the point.
You don't see the point of fixing the TAP Parse error? :-D
>
Junio C Hamano wrote:
[...]
> As I am more worried about longer-term health of the codebase, what
> the part you moved outside test_expect_* with this patch happens to
> do _right now_ is of secondary importance, at least from my point of
> view. The next patch that updates this scirpt may want to
Jonathan Nieder wrote:
> [...]
>> No, I don't think this would be a good direction to go in. This may
>> not be a good idea either, but if you wanted to add a check here, then
>> maybe something like this (totally untested):
>>
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> index acda33d..53a2422
On 07/25/2012 05:14 AM, David Aguilar wrote:
> Symlinks are not ubiquitous on Windows so make --no-symlinks the default.
>
> Signed-off-by: David Aguilar
> ---
> I don't have cygwin so I can't verify this one myself.
> Is 'cygwin' really the value of $^O there?
>
Apparently yes:
$ uname -rso
Has anyone else noticed false positives coming from the
orphan check? It is warning me about commits that are
clearly on master. Here is an example, where I checkout
master~2 and then switch back to master. It somehow thinks
that master~2 is orphaned, when master~2 is by definition
in the commit
Stefan Zager writes:
> Currently, it will only do a checkout if the sha1 registered in the containing
> repository doesn't match the HEAD of the submodule, regardless of whether the
> submodule is dirty. As discussed on the mailing list, the '--force' flag is a
> strong indicator that the state
On Wed, Jul 25, 2012 at 9:49 AM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> Keep the temporary directory around when either compare() or
>> the difftool returns a non-zero exit status.
>>
>> Tell the user about the location of the temporary files so that
>> they can recover from the failu
Peng Yu writes:
> Hi,
>
> I have the following in .gitignore to ignore *.txt files.
>
> *.txt
>
> But I want to keep the *.txt files in, for example, data/ and all its
> subdirectories. I don't know should the the correct way to unignore
> these *.txt files. Could anybody show me the command that
Currently, it will only do a checkout if the sha1 registered in the containing
repository doesn't match the HEAD of the submodule, regardless of whether the
submodule is dirty. As discussed on the mailing list, the '--force' flag is a
strong indicator that the state of the submodule is suspect, an
Tay Ray Chuan writes:
> If suggestions are available (based on Levenshtein distance) and if the
> terminal isatty(), present a prompt to the user to select one of the
> computed suggestions.
The way to determine "If the terminal is a tty" used in this patch
looks overly dangerous, given that we
Tay Ray Chuan writes:
> When help.autocorrect is set, in an attempt to retain the memory to the
> string name in main_cmds, we unfortunately leaked the struct cmdname
> that held it. Fix this by creating a copy of the string name.
If you are updating help_unknown_cmd() so that the caller can fre
Tay Ray Chuan writes:
> Copying with structural assignment may not take into account that the
> LHS struct has sufficient memory, especially since the cmdname->name
> member is nonfixed in size. Be unambiguous about it by realloc()'ing it
> to be of sufficient size.
If the original code were
Jiang Xin writes:
> Mark strings in 'git-am.sh' for translation. In the last chunk, I
> changed '$1' to '-b/--binary' for this reason:
>
> * First, if there is a variable in the l10n message, we could not use
>gettext. Because the variable will be expanded (evaluated) and will
>never mat
Jiang Xin writes:
> The obsolete LONG_USAGE variable has the following message in it:
>
> A'\''--B'\''--C'\''
>
> And such complex LONG_USAGE message will break xgettext when
> extracting l10n messages. But if single quotes are removed from
> the message, xgettext works fine on 'git-rebase.sh
Looks sensible. Will queue.
Thanks.
--
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
David Aguilar writes:
> Keep the temporary directory around when either compare() or
> the difftool returns a non-zero exit status.
>
> Tell the user about the location of the temporary files so that
> they can recover from the failure.
>
> Signed-off-by: David Aguilar
> ---
> git-difftool.perl
Thanks.
--
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
On Fri, Jul 20, 2012 at 11:42 AM, Thiago Farina wrote:
> Is there any interest in building git with ninja? [1]. I think it
> would be very interesting to move forward from make to ninja.
>
> [1] http://martine.github.com/ninja/
While it might be interesting, would it be a productive use of the
co
If suggestions are available (based on Levenshtein distance) and if the
terminal isatty(), present a prompt to the user to select one of the
computed suggestions.
In the case where there is a single suggestion, present the prompt
"[Y/n]", such that "" (ie. the default), "y" and "Y" as input leads
When help.autocorrect is set, in an attempt to retain the memory to the
string name in main_cmds, we unfortunately leaked the struct cmdname
that held it. Fix this by creating a copy of the string name.
When help.autocorrect is not set, we exit()'d without free'ing it like
we do when the config is
Copying with structural assignment may not take into account that the
LHS struct has sufficient memory, especially since the cmdname->name
member is nonfixed in size. Be unambiguous about it by realloc()'ing it
to be of sufficient size.
Additionally, free the unused cmdnames, which are no longer a
From: Jeff King
We observe that the j-1 element can serve the same purpose as the i-1
element that we use in the strcmp(); it is either:
1. Exactly i-1, when the loop begins (and until we see a duplicate).
2. The same pointer that was stored at i-1 (if it was not a duplicate,
and we ju
Patch 4 has the meat of this series.
While running valgrind to check that I didn't leak any memory, a couple
of leaks were spotted. Patches 1-3 address them.
Major change in v2: implement Thomas' idea [1] about using
help.autocorrect to configure this behaviour.
[1] <878vh4con4@thomas.inf.et
Hi,
I have the following in .gitignore to ignore *.txt files.
*.txt
But I want to keep the *.txt files in, for example, data/ and all its
subdirectories. I don't know should the the correct way to unignore
these *.txt files. Could anybody show me the command that I should add
to .gitignore? Than
Hi Doug,
The method I have been using to achieve this is to create a wrapper script that
does the following:
git clone -n # clone, but don't checkout
cd
git config core.sparseCheckout true# configure sparse-checkout on
# echo the lis
Mark strings in merge-recursive for translation.
Some tests would start to fail with GETTEXT_POISON turned on after
this update. Use test_i18ncmp and test_i18ngrep where appropriate
to mark strings that should only be checked in the C locale output
to avoid such issues.
Signed-off-by: Jiang Xin
Found this dead code when I examine gettext messages in shell scripts
start with dash ('-' or '--'). An error will be raised for this case,
like:
$ gettext "-d option is no longer supported. Do not use."
gettext: missing arguments
Indead, this code has been left as dead for a long time,
The obsolete LONG_USAGE variable has the following message in it:
A'\''--B'\''--C'\''
And such complex LONG_USAGE message will break xgettext when
extracting l10n messages. But if single quotes are removed from
the message, xgettext works fine on 'git-rebase.sh'.
Since there is a modern OPTI
Mark strings in 'git-am.sh' for translation. In the last chunk, I
changed '$1' to '-b/--binary' for this reason:
* First, if there is a variable in the l10n message, we could not use
gettext. Because the variable will be expanded (evaluated) and will
never match the entry in the po file.
Gettext message in a shell script should not start with '-', one
workaround is adding '--' between gettext and the message, like:
gettext -- "--exec option ..."
But due to a bug in the xgettext extraction, xgettext can not
extract the actual message for this case. Rewriting the message
is a s
Mark messages in git-rebase.sh for translation. While doing this
Jonathan noticed that the comma usage and sentence structure of the
resolvemsg was not quite right, so correct that and its cousins in
git-am.sh and t/t0201-gettext-fallbacks.sh at the same time.
Some tests would start to fail with
Since we have additional shell wrappers (gettextln and eval_gettextln)
for gettext, we need to take into account these wrappers when running
'make pot' to extract messages from shell scripts.
Signed-off-by: Jiang Xin
Reviewed-by: Stefano Lattarini
Reviewed-by: Jonathan Nieder
---
Makefile | 3
[Sorry, bad patch series number, resend again. I'm sleepy.]
Marked messages for translation in git-am, git-rebase, and git-merge.
Also fixed suffered tests when turning GETTEXT_POISON switch on.
Jiang Xin (7):
i18n: New keywords for xgettext extraction from sh
i18n: rebase: mark messages for
Mark strings in merge-recursive for translation.
Some tests would start to fail with GETTEXT_POISON turned on after
this update. Use test_i18ncmp and test_i18ngrep where appropriate
to mark strings that should only be checked in the C locale output
to avoid such issues.
Signed-off-by: Jiang Xin
Found this dead code when I examine gettext messages in shell scripts
start with dash ('-' or '--'). An error will be raised for this case,
like:
$ gettext "-d option is no longer supported. Do not use."
gettext: missing arguments
Indead, this code has been left as dead for a long time,
Mark strings in 'git-am.sh' for translation. In the last chunk, I
changed '$1' to '-b/--binary' for this reason:
* First, if there is a variable in the l10n message, we could not use
gettext. Because the variable will be expanded (evaluated) and will
never match the entry in the po file.
The obsolete LONG_USAGE variable has the following message in it:
A'\''--B'\''--C'\''
And such complex LONG_USAGE message will break xgettext when
extracting l10n messages. But if single quotes are removed from
the message, xgettext works fine on 'git-rebase.sh'.
Since there is a modern OPTI
Gettext message in a shell script should not start with '-', one
workaround is adding '--' between gettext and the message, like:
gettext -- "--exec option ..."
But due to a bug in the xgettext extraction, xgettext can not
extract the actual message for this case. Rewriting the message
is a s
Mark messages in git-rebase.sh for translation. While doing this
Jonathan noticed that the comma usage and sentence structure of the
resolvemsg was not quite right, so correct that and its cousins in
git-am.sh and t/t0201-gettext-fallbacks.sh at the same time.
Some tests would start to fail with
Since we have additional shell wrappers (gettextln and eval_gettextln)
for gettext, we need to take into account these wrappers when running
'make pot' to extract messages from shell scripts.
Signed-off-by: Jiang Xin
Reviewed-by: Stefano Lattarini
Reviewed-by: Jonathan Nieder
---
Makefile | 3
Marked messages for translation in git-am, git-rebase, and git-merge.
Also fixed suffered tests when turning GETTEXT_POISON switch on.
Jiang Xin (7):
i18n: New keywords for xgettext extraction from sh
i18n: rebase: mark messages for translation
i18n: Rewrite gettext messages start with dash
2012/7/25 Jonathan Nieder :
> Jiang Xin wrote:
> s/Junathan/Jonathan/, please, unless you are trying to say that both
> Junio and I pointed it out at the same time.
Sorry. Correct it in next series of patches.
I don't know how this happens until now.
--
Jiang Xin
--
To unsubscribe from this list
Jiang Xin wrote:
> Found this dead code when I examine gettext messages in shell scripts
> start with dash ('-' or '--'). An error will be raised for this case,
> like:
>
> $ gettext "-d option is no longer supported. Do not use."
> gettext: missing arguments
>
> Indead, this code has bee
On Wed, Jul 18, 2012 at 3:27 AM, Jeff King wrote:
> On Tue, Jul 17, 2012 at 10:10:25PM -0700, Junio C Hamano wrote:
>
>> Ping on a seemingly stalled thread.
> If I did not simply dream it, can you re-post the latest patch you
> sent?
>
> -Peff
...And I thought dreaming I was trapped in a DOS pro
2012/7/25 Stefano Lattarini :
>> * Second, if there is a positional parameter ($1, $2,...) in the
>>message, we could not use eval_gettext either. Because
>>eval_gettext may be a wapper for gettext, and the positional
>>parameter would loose it's original context.
>>
> ... here you sho
Sorry to be so nit-picky, but ...
On 07/25/2012 05:53 AM, Jiang Xin wrote:
> Mark strings in 'git-am.sh' for translation. In the last chunk, I
> changed '$1' to '-b/--binary' for this reason:
>
> * First, if there is a variable in the l10n message, we could not use
>gettext. Because the vari
On 2012.7.25 12:14 AM, Junio C Hamano wrote:
>> Nothing, because paths are not URI escaped. :)
>>
>> You probably meant svn_uri_canonicalize(). And no, it does not double
>> escape,
>> so its safe to escape as early as possible.
>
> Are you saying that the function assumes that a local pathname
Jiang Xin wrote:
> 2012/7/25 Jonathan Nieder :
>> I haven't tested or reviewed this patch in detail, so even though it
>> looks good, I'd prefer it not to have my Reviewed-by. (See
>> Documentation/SubmittingPatches: '"Reviewed-by:", unlike the other
>> extra tags, can only be offered by the revi
Mark strings in 'git-am.sh' for translation. In the last chunk, I
changed '$1' to '-b/--binary' for this reason:
* First, if there is a variable in the l10n message, we could not use
gettext. Because the variable will be expanded (evaluated) and will
never match the entry in the po file.
Mark strings in merge-recursive for translation.
Some test scripts are affected by this update, and would fail if tested
with GETTEXT_POISON switch turned on. Using i18n-specific test
functions, such as test_i18ngrep, in the related test scripts will fix
these issues.
Signed-off-by: Jiang Xin
Re
Found this dead code when I examine gettext messages in shell scripts
start with dash ('-' or '--'). An error will be raised for this case,
like:
$ gettext "-d option is no longer supported. Do not use."
gettext: missing arguments
Indead, this code has been left as dead for a long time,
The obsolete LONG_USAGE variable has the following message in it:
A'\''--B'\''--C'\''
And such complex LONG_USAGE message will breaks xgettext when extracting
l10n messages. But if single quotes are removed from the message, xgettext
works fine on 'git-rebase.sh'.
Since there is a modern OPT
Gettext message in a shell script should not start with '-', one
workaround is adding '--' between gettext and the message, like:
gettext -- "--exec option ..."
But due to a bug in the xgettext extraction, xgettext can not
extract the actual message for this case. Rewriting the message
is a s
Mark messages in git-rebase.sh for translation. While doing this
Jonathan noticed that the comma usage and sentence structure of the
resolvemsg was not quite right, so correct that and its cousins in
git-am.sh and t/t0201-gettext-fallbacks.sh at the same time.
Some tests would start to fail with
Since we have additional shell wrappers (gettextln and eval_gettextln)
for gettext, we need to take into account these wrappers when running
'make pot' to extract messages from shell scripts.
Signed-off-by: Jiang Xin
Reviewed-by: Stefano Lattarini
Reviewed-by: Jonathan Nieder
---
Makefile | 3
Marked messages for translation in git-am, git-rebase, and git-merge.
Also fixed suffered tests when turning GETTEXT_POISON switch on.
Jiang Xin (7):
i18n: New keywords for xgettext extraction from sh
i18n: rebase: mark messages for translation
i18n: Rewrite gettext messages start with dash
2012/7/25 Jonathan Nieder :
> I haven't tested or reviewed this patch in detail, so even though it
> looks good, I'd prefer it not to have my Reviewed-by. (See
> Documentation/SubmittingPatches: '"Reviewed-by:", unlike the other
> extra tags, can only be offered by the reviewer'.) If you'd like t
Michael G Schwern writes:
> On 2012.7.24 9:53 PM, Jonathan Nieder wrote:
>> Michael G Schwern wrote:
>>
>>> No, now it's just canonicalizing as early as possible. Preferably within
>>> the
>>> object accessor rather than at the point of use. So in the code below,
>>> $full_url is already esca
96 matches
Mail list logo
