[PATCH] i18n: fix small typos

[Jean-Noël Avila]

Translating the new strings introduced for v2.20 showed some typos.

Signed-off-by: Jean-Noël Avila 
---
 http.c | 2 +-
 midx.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/http.c b/http.c
index 3dc8c560d6..eacc2a75ef 100644
--- a/http.c
+++ b/http.c
@@ -834,7 +834,7 @@ static CURL *get_curl_handle(void)
 #if LIBCURL_VERSION_NUM >= 0x072c00
curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, 
CURLSSLOPT_NO_REVOKE);
 #else
-   warning(_("CURLSSLOPT_NO_REVOKE not suported with cURL < 
7.44.0"));
+   warning(_("CURLSSLOPT_NO_REVOKE not supported with cURL < 
7.44.0"));
 #endif
}
 
diff --git a/midx.c b/midx.c
index 730ff84dff..2a6a24fcd7 100644
--- a/midx.c
+++ b/midx.c
@@ -202,7 +202,7 @@ int prepare_midx_pack(struct multi_pack_index *m, uint32_t 
pack_int_id)
struct strbuf pack_name = STRBUF_INIT;
 
if (pack_int_id >= m->num_packs)
-   die(_("bad pack-int-id: %u (%u total packs"),
+   die(_("bad pack-int-id: %u (%u total packs)"),
pack_int_id, m->num_packs);
 
if (m->packs[pack_int_id])
-- 
2.18.0

Help on autocompletion not localized?

[Jean-Noël Avila]

Hi,


When invoking the autocompletion help with  after a double
hyphen under zsh, the help list is not localized. I guess the help list
comes from some usage output of the on-going git command, but I wasn't
able to find where and how this happens (completion scripts are quite
hairy).


Thanks

Re: [PATCH] i18n: fix dangling dot in die() messages

[Jean-Noël Avila]

On 04/09/2018, Ævar Arnfjörð Bjarmason wrote:On Tue, Sep 4, 2018 at 4:59
PM Jean-Noel Avila  wrote:
> Your commit message says "dangling dot"...

The dot is dangling on its own line. I don't really catch why this would
be needed.

>
>> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
>> index b56028ba9d..a011abfd7c 100644
>> --- a/builtin/submodule--helper.c
>> +++ b/builtin/submodule--helper.c
>> @@ -521,7 +521,7 @@ static void runcommand_in_submodule_cb(const struct 
>> cache_entry *list_item,
>> printf(_("Entering '%s'\n"), displaypath);
>>
>> if (info->argv[0] && run_command())
>> -   die(_("run_command returned non-zero status for %s\n."),
>> +   die(_("run_command returned non-zero status for %s"),
> ...but here and below you're also removing the newline. Is this
> intended, and does it work as desired afterwards? I.e. were we just
> ignoring the \n?
>

I checked that usually, the die command does not have the final dot nor
a new line. But I'm not sure of what's intended here.

Re: [PATCH] i18n: fix mistakes in translated strings

[Jean-Noël AVILA]

Le jeudi 23 août 2018, 23:28:55 CEST Junio C Hamano a écrit :
> Jean-Noël Avila  writes:
> 
> > -   die(_("run_command returned non-zero status while"
> > +   die(_("run_command returned non-zero status while "
> > "recursing in the nested submodules of %s\n."),
> 
> Obviously good.
> 
> > diff --git a/config.c b/config.c
> > index 9a0b10d4bc..3461993f0a 100644
> > --- a/config.c
> > +++ b/config.c
> > @@ -124,7 +124,7 @@ static const char include_depth_advice[] = N_(
> >  "  %s\n"
> >  "from\n"
> >  "  %s\n"
> > -"Do you have circular includes?");
> > +"This might be due to circular includes.");
> 
> OK.
Hello,

Has this patch been integrated in a -rc? In which case, would a new round of 
translation need to be triggered?

Thanks

JN

[PATCH] i18n: fix mistakes in translated strings

[Jean-Noël Avila]

Fix typos and convert a question which does not expect to be replied
to a simple advice.

Signed-off-by: Jean-Noël Avila 
---
 builtin/submodule--helper.c | 2 +-
 config.c| 2 +-
 sequencer.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 2bcc70fdfe..b56028ba9d 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -542,7 +542,7 @@ static void runcommand_in_submodule_cb(const struct 
cache_entry *list_item,
argv_array_pushv(, info->argv);
 
if (run_command())
-   die(_("run_command returned non-zero status while"
+   die(_("run_command returned non-zero status while "
"recursing in the nested submodules of %s\n."),
displaypath);
}
diff --git a/config.c b/config.c
index 9a0b10d4bc..3461993f0a 100644
--- a/config.c
+++ b/config.c
@@ -124,7 +124,7 @@ static const char include_depth_advice[] = N_(
 "  %s\n"
 "from\n"
 "  %s\n"
-"Do you have circular includes?");
+"This might be due to circular includes.");
 static int handle_path_include(const char *path, struct config_include_data 
*inc)
 {
int ret = 0;
diff --git a/sequencer.c b/sequencer.c
index 65d371c746..84bf598c3e 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -720,7 +720,7 @@ static const char *read_author_ident(struct strbuf *buf)
/* dequote values and construct ident line in-place */
for (in = buf->buf; i < 3 && in - buf->buf < buf->len; i++) {
if (!skip_prefix(in, keys[i], (const char **))) {
-   warning(_("could not parse '%s' (looking for '%s'"),
+   warning(_("could not parse '%s' (looking for '%s')"),
rebase_path_author_script(), keys[i]);
return NULL;
}
-- 
2.18.0

Re: [PATCH 1/2] l10n: fr: fix a message seen in git bisect

[Jean-Noël Avila]

OK, Will queue this patch for next round of translation

Re: is http://git-scm.com an *official* git-affiliated site?

[Jean-Noël Avila]

On 07/02/2018, Jeff King wrote:

> On Wed, Feb 07, 2018 at 12:37:32PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>
>> It's not fully auto-generated so stuff like git-worktree doesn't get
>> added automatically, I just added a PR for that:
>> https://github.com/git/git-scm.com/pull/1133
> Thanks for doing that. I'm also open to auto-generating the index if we
> can come up with well-organized output.
>
> -Peff


I did not know that git-worktree is not considered ready for general
consumption. It has been present in the release notes for quite some
time now.


If there's something available from the git repo to drive the build of
the index, that would be a good way to advert the publicly available
commands of git.


JN

Re: [PATCH] fix french translation

[Jean-Noël AVILA]

On Wednesday, 22 November 2017 18:24:40 CET Louis Bettens wrote:
> Signed-off-by: Louis Bettens 
> ---
>  po/fr.po | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/po/fr.po b/po/fr.po
> index 4deae3318..a12a2ae37 100644
> --- a/po/fr.po
> +++ b/po/fr.po
> @@ -14331,7 +14331,7 @@ msgstr "git worktree add []  
> []"
>  
>  #: builtin/worktree.c:17
>  msgid "git worktree list []"
> -msgstr "git worktree prune []"
> +msgstr "git worktree list []"
>  
>  #: builtin/worktree.c:18
>  msgid "git worktree lock [] "
> 

Good catch! I guess the segment switched directly from fuzzy to translated.

I'll queue it for the next version which we should not wait for long.

Thanks

Re: [PATCH] submodule: avoid sentence-lego in translated string

[Jean-Noël AVILA]

On Monday, 9 October 2017, 09:47:26 CEST Stefan Beller wrote:

> I always assumed that translators are aware of these issues and sort of
> work around this somehow, maybe like this:
> 
>   "submodule entry '%s' (%s) is not a commit. It is of type %s"

Translators can be aware of the issue if the coder commented the 
internationalization string with some possible candidates for the placeholders 
when it is not clear unless you check in the source code. Much effort was 
poured into translating the technical terms in other parts of Git; it seems 
awkward to just step back in this occurence.

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

[Jean-Noël AVILA]

Le 22/07/2017 à 02:43, Jiang Xin a écrit :
>
> Benefit of using the tweak version of gettext:
>
> 1. `make pot` can be run in a tar extract directory (without git controlled).

This issue is real for packet maintainers who can patch the original
source and run their own set of utilities outside of a git repo. This
can be possible with Junio's proposition by writing the files to a
temporary directory before running the xgettext, then removing the
temporary directory.

Please note that with respect to this issue, the patched xgettext
approach is completely disruptive.

> 2. do not need to run `git reset --hard`.

Same as before.

> 3.  it's quick (nobody cares).
>

Requiring patched tools is really breaking collaboration. Git made a
great case of relying on standard tools (not even GNU versions), so that
would really go backward.


Plus, I hope that some day, instead of translators finding afterwards
that a change broke i18n capabilities, developpers would have some kind
of sanity check. Requiring special versions of i18n tooling stops this hope.

<>

Re: [L10N] Kickoff of translation for Git 2.14.0 round 1

[Jean-Noël Avila]

Le 22/07/2017 à 19:02, Kaartic Sivaraam a écrit :
> On Sat, 2017-07-15 at 21:30 +0200, Jean-Noël Avila wrote:
>>  * commit 4ddb1354e8 ("status: contextually notify user about an initial
>> commit") plays sentence lego while introducing colorization which again
>> does not play well with i18n.
>>
> What, if anything, should be done about this?
>

I only spotted it because the string is new for translation. But the
previous version was already playing sentence lego. So this is not a
regression ;-)


If I understand correctly, getting a i18n friendly string would require
being able to "color_sprintf" the branche name, and then "color_fprintf"
the output with a %s formatting string. None of this is already
available and that would introduce cumbersome logic in the code.


More generally, i18n puts some pressure on coding style for sure, and it
gets worse with multi-platform and coloring... how can we ease the
burden of developpers on this front without resorting to ad hoc patches?

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

[Jean-Noël Avila]

Le 20/07/2017 à 20:57, Junio C Hamano a écrit :
>
> + git diff --quiet HEAD && git diff --quiet --cached
> +
> + @for s in $(LOCALIZED_C) $(LOCALIZED_SH) $(LOCALIZED_PERL); \

Does PRIuMAX make sense for perl and sh files?

> + do \
> + sed -e 's|PRItime|PRIuMAX|g' <"$$s" >"$$s+" && \
> + cat "$$s+" >"$$s" && rm "$$s+"; \
> + done
> +
>   $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ $(XGETTEXT_FLAGS_C) $(LOCALIZED_C)
>   $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing $(XGETTEXT_FLAGS_SH) 
> \
>   $(LOCALIZED_SH)
>   $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing 
> $(XGETTEXT_FLAGS_PERL) \
>   $(LOCALIZED_PERL)
> +
> + git reset --hard
>   mv $@+ $@
>  
>  .PHONY: pot

Re: [L10N] Kickoff of translation for Git 2.14.0 round 1

[Jean-Noël Avila]

Le 15/07/2017 à 07:06, Jiang Xin a écrit :
> Hi,
>
> Git v2.14.0-rc0 has been released, and it's time to start new round of git 
> l10n.
> This time there are 30+ updated messages need to be translated since last
> update:
>
> l10n: git.pot: v2.14.0 round 1 (34 new, 23 removed)
>
> Generate po/git.pot from v2.14.0-rc0 for git v2.14.0 l10n round 1.
>
> Signed-off-by: Jiang Xin 
>
> You can get it from the usual place:
>
> https://github.com/git-l10n/git-po/
>
> As how to update your XX.po and help to translate Git, please see
> "Updating a XX.po file" and other sections in “po/README" file.
>
> --
> Jiang Xin
Hi all,


A few remarks on i18n:

 * commit cb71f8bdb5 ("PRItime: introduce a new "printf format" for
timestamps") does not play well with i18n framework. The static string
concatenation cannot be correctly interpreted by msgmerge. I don't know
how we can combine variable format indicators with translatable strings.

 * commit 4ddb1354e8 ("status: contextually notify user about an initial
commit") plays sentence lego while introducing colorization which again
does not play well with i18n.


Thank you.

Re: [PATCH v3 2/3] read-tree -m: make error message for merging 0 trees less smart aleck

[Jean-Noël AVILA]

On Friday, 12 May 2017, 15:28:53 CEST Junio C Hamano wrote:
> Jonathan Nieder  writes:
> 
> >> @@ -226,9 +226,10 @@ int cmd_read_tree(int argc, const char **argv, const 
> >> char *unused_prefix)
> >>setup_work_tree();
> >>  
> >>if (opts.merge) {
> >> -  if (stage < 2)
> >> -  die("just how do you expect me to merge %d trees?", 
> >> stage-1);
> >>switch (stage - 1) {
> >> +  case 0:
> >> +  die(_("you must specify at least one tree to merge"));
> >> +  break;
> >
> > This part looks good.
> 
> Thanks.  Modulo _(""); I do not think other messages from read-tree
> are marked for i18n (yet).
> 

The documentation is already i18n, but not the dying messages. This can take 
place in a specific patch series.

Thanks. Will reroll. 

Re: What's cooking in git.git (May 2017, #03; Wed, 10)

[Jean-Noël AVILA]

Le mercredi 10 mai 2017, 10:08:14 CEST Ævar Arnfjörð Bjarmason a écrit :
> > * ja/doc-l10n (2017-03-20) 3 commits
> >  . SQUASH???
> >  . l10n: add git-add.txt to localized man pages
> >  . l10n: introduce framework for localizing man pages
> >
> >  A proposal to use po4a to localize our manual pages.
> >
> >  Will discard.
> >  Has been stalled for too long.
> 
> Jean-Noel: Need any help with this?
> 

I restarted on this yesterday. The change for git will be reduced to what Junio 
proposed, that is embedding a repo into /Documentation, with some targets added 
to Makefile if the directory is present. In the doc l10n repo, a Makefile's 
target will copy the asciidoc source files from /Documentation into the repo, 
in order to create a stable base for all the po4a stuff.

This is quite slow as my Makefile-fu is very basic.

Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required

[Jean-Noël AVILA]

Le jeudi 4 mai 2017, 10:14:58 CEST Kerry, Richard a écrit :
> 
> My point was to ensure that where English is used on-screen it should make 
> sense, which in this particular case it didn't (a French idiom which, on 
> using an automatic translator, didn't make sense in English).  The same of 
> course applies to other languages used on-screen.
> 
> I agree about ensuring that the application doesn't elicit a response that it 
> won't, or can't, actually handle.  A rhetorical question is fine, so long as 
> it is clear that the program won't accept any further input.
> 
> Though I don't agree about the issue of the length of words, as presented to 
> a non-native speaker.  Sometimes a longer word can be very specific in its 
> meaning, and can be looked up in a dictionary if the reader is not familiar 
> with it.  Sometimes using shorter words can result in a less clear meaning, 
> or perhaps be an idiomatic usage, which might be missed by a non-native 
> speaker.
> 

Thanks. So what's the status of this patch series? I don't buy the idea of 
rhetorical HMI. That's a sure way to confuse non-native speakers. Please note 
that I kept the questions when there is a following text. Only questions 
addressing the user at the end of output have been rephrased.

For the "do you mean" questions, the proposition would then simply be: "the 
most similar command is:" or "the most similar commands are:".

and then  what about the other patches?

Thanks


> Regards,
> Richard.
> 
> 
> 
> 
> Richard Kerry
> BNCS Engineer, SI SOL Telco & Media Vertical Practice
> T: +44 (0)20 3618 2669
> M: +44 (0)7812 325518
> 4 Triton Square, Regent’s Place, London NW1 3HG
> richard.ke...@atos.net
> 
> 
> This e-mail and the documents attached are confidential and intended solely 
> for the addressee; it may also be privileged. If you receive this e-mail in 
> error, please notify the sender immediately and destroy it. As its integrity 
> cannot be secured on the Internet, the Atos group liability cannot be 
> triggered for the message content. Although the sender endeavours to maintain 
> a computer virus-free network, the sender does not warrant that this 
> transmission is virus-free and will not be liable for any damages resulting 
> from any virus transmitted.
> 
> 
> From: Ævar Arnfjörð Bjarmason [ava...@gmail.com]
> Sent: 04 May 2017 10:09
> To: Kerry, Richard
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH v2 1/3] usability: don't ask questions if no reply is 
> required
> 
> On Thu, May 4, 2017 at 10:52 AM, Kerry, Richard  
> wrote:
> >
> > May I suggest that " The most approaching commands" doesn't make much sense 
> > as English (I don't think a command can "approach").
> > Perhaps it should be " The most appropriate commands".
> 
> I had the same concern, saying "appropriate" is IMO also confusing.
> The point of this UI is not to point out what you should be running,
> which "appropriate" implies, but just "we couldn't find what you
> meant, did you mean one of these?".
> 
> I think nothing needs to change here. The whole premise here is that a
> program should never ask a question when you can't give an answer, I
> think that's nonsense. There's such a thing as a rhetorical question,
> and sometimes using that form is the most obvious & succinct way to
> put things.
> 
> Which is not to say that phrasing these things as a non-question can't
> be better, but the suggestions so far just seem more complex.
> 
> Also keep in mind that a huge part of the user base for git using the
> English UI consists of non-native speakers, and when in doubt we
> should definitely be picking simpler English like "did you mean?" v.s.
> alternatives with >10 character more obscure words.
> 
> > Richard Kerry
> > BNCS Engineer, SI SOL Telco & Media Vertical Practice
> >
> > T: +44 (0)20 3618 2669
> > M: +44 (0)7812 325518
> > Lync: +44 (0) 20 3618 0778
> > Room G300, Stadium House, Wood Lane, London, W12 7TA
> > richard.ke...@atos.net
> >
> >
> >
> >
> > -Original Message-
> > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On 
> > Behalf Of Jean-Noel Avila
> > Sent: Wednesday, May 03, 2017 10:07 PM
> > To: git@vger.kernel.org
> > Cc: rashmipa...@gmail.com; Jean-Noel Avila 
> > Subject: [PATCH v2 1/3] usability: don't ask questions if no reply is 
> > required
> >
> > There has been a bug report by a corporate user that stated that "spelling 
> > mistake of stash followed by a yes prints character 'y'
> > infinite times."
> >
> > This analysis was false. When the spelling of a command contains errors, 
> > the git program tries to help the user by providing candidates which are 
> > close to the unexisting command. E.g Git prints the
> > following:
> >
> > git: 'stahs' is not a git command. See 'git --help'.
> > Did you mean this?
> >
> > stash
> >
> > and then exits.
> >
> > The problem with this hint is that it 

Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required

[Jean-Noël AVILA]

Le jeudi 4 mai 2017, 08:52:43 CEST Kerry, Richard a écrit :
> 
> May I suggest that " The most approaching commands" doesn't make much sense 
> as English (I don't think a command can "approach").
> Perhaps it should be " The most appropriate commands".
> 
> 
> Regards,
> Richard.
> 



Thank you for your proposition. "approaching" is a frenchism  doubled with 
google translate (sorry!). Maybe "similar" would also work.
  

Re: [PATCH 3/4] read-tree.c: rework UI when merging no trees

[Jean-Noël AVILA]

Le mercredi 3 mai 2017, 10:04:01 CEST Jonathan Nieder a écrit :
> Hi,
> 
> Jean-Noel Avila wrote:
> > Subject: read-tree.c: rework UI when merging no trees
> 
> nit: this is about user-facing behavior, not an implementation detail,
> so the part before the colon can be the command that changed
> (read-tree:).
> 
> nit: the word "rework" is dangerous in a commit message in the same
> way as the word "fix" --- it stands for "make better", in a vague way
> that leaves the reader guessing about how.  Usually a more specific
> description can work better.
> 

In fact, this patch is two fold:

 * reword the question in the die() call. I realize now that when passed to 
die(), the string is prepended with "fatal:". That's an hint that the question 
does not require a reply, but  ruling out any doubt would be better.
 * rework the local logic which was inherited from history. This is 
functionally equivalent to the previous version, just cleaner.

> > The initial test was inherited from a previous commit, but it is no
> > longer needed, given the following switch case. Moreover, the question
> > sentence ending the program has been replace by an assertative one.
> > 
> > Signed-off-by: Jean-Noel Avila 
> 
> This can have a simpler, short-and-sweet motivation:
> 
>   read-tree -m: make error message for merging 0 trees less smart-alecky
> 
>   "git read-tree -m" requires a tree argument to name the tree to be
>   merged in.  Git uses a cutesy error message to say so and why:
> 
>   $ git read-tree -m
>   warning: read-tree: emptying the index with no arguments is 
> deprecated;
> use --empty fatal: just how do you expect me to merge 0 trees?
>   $ git read-tree -m --empty
>   fatal: just how do you expect me to merge 0 trees?
> 
>   When lucky, that could produce an ah-hah moment for the user, but it's
>   more likely to irritate and distract them.
> 
>   Instead, tell the user plainly that the tree argument is required. Also
>   document this requirement in the git-read-tree(1) manpage where there is
>   room to explain it in a more straightforward way.
> 

Thank you very much for this message! May I s-o-b you?

As hinted, I'll add the documentation part. ;-)

> Unfortunately both 'git read-tree -h' and 'git read-tree --help' say nothing
> about this.  Ideas for wording there?

Next pach series will propose this.

> 
> Thanks and hope that helps,
> Jonathan

Re: [PATCH 2/4] usability: fix am and checkout for nevermind questions

[Jean-Noël AVILA]

Le mercredi 3 mai 2017 09:51:58 CEST, vous avez écrit :
> Jean-Noel Avila wrote:
> > Subject: usability: fix am and checkout for nevermind questions
> > 
> > Signed-off-by: Jean-Noel Avila 
> 
> Thanks for working on improving Git's UX.  I agree with the goal in
> general (we should not gratuitously surprise users) but I think I
> lack context for appreciating this particular example.
> 
> This is a good place to describe the motivation behind the patch and
> what effective change it would have.
> 
> [...]
> 
> > +++ b/builtin/am.c
> 
> [...]
> 
> > if (is_empty_file(am_path(state, "patch"))) {
> > 
> > -   printf_ln(_("Patch is empty. Was it split wrong?"));
> > +   printf_ln(_("Patch is empty. It may have been split wrong."));
> 
> [...]
> 
> > if (unmerged_cache()) {
> > 
> > printf_ln(_("You still have unmerged paths in your index.\n"
> > 
> > -   "Did you forget to use 'git add'?"));
> > +   "You might want to use 'git add' on them."));
> 
> [...]
> 
> > if (opts.new_branch && argc == 1)
> > 
> > die(_("Cannot update paths and switch to branch '%s' at 
> > the same
> > time.\n"
> > 
> > - "Did you intend to checkout '%s' which can not be 
> > resolved 
as
> > commit?"), +  "'%s' can not be resolved as 
> > commit, but it
> > should."),
> 
> In the current state I think this patch makes things worse (questions
> are not automatically a bad thing), which would make it especially
> useful to see more about the motivation so we can find out whether
> there's another way.
> 

I am not a UX designer, but for me, in the context of interaction with a 
command line program, any question that does not accept a reply is bad design. 
That also means that any command that does not run interactively should not 
ask questions. The shell interface is too informal to allow being loose on the 
program side. Comparatively to a GUI, where a label is formally informative 
and a popping-up dialog box asks for user input.

This patch should indeed be squashed with the first one. They are small changes 
in strings printed when dying.  They would share the more extended commit 
message.

Re: [PATCH 1/4] usability: don't ask questions if no reply is required

[Jean-Noël AVILA]

Le mercredi 3 mai 2017, 09:47:44 CEST Jonathan Nieder a écrit :
> Hi,
> 
> Jean-Noel Avila wrote:
> > As described in the bug report at
> > 
> > https://github.com/git/git-scm.com/issues/999
> 
> External issue tracker URLs have been known to change or disappear and
> we try to make commit messages self-contained instead of relying on
> them.  It is common to put a 'Requested-by:' footer or sentence saying
> 'Requested at  by ' near the bottom of a commit message
> for attribution and context.  Relying on the bug report more heavily
> like this example (instead of including any relevant information)
> makes it harder for a reader to understand the patch easily in
> one place.
> 
> In other words, instead of asking the reader to read the bug report,
> please include pertinent information the reader needs to
> understand the patch here so they don't have to.

Ok. Will include more context in the commit message and just provide the BT as 
an additional link.

> 
> > the user was disconcerted by the question asked by the program not
> > requiring a reply from the user. To improve the general usability of
> > the Git suite, The following rule was applied:
> > 
> > if the sentence
> > 
> >  * appears in a non-interactive session
> >  * is printed last before exit
> >  * is a question addressing the user ("you")
> > 
> > the sentence is turned into affirmative and proposes the option.
> > 
> > Signed-off-by: Jean-Noel Avila 
> > ---
> > 
> >  help.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/help.c b/help.c
> > index bc6cd19cf..4658a55c6 100644
> > --- a/help.c
> > +++ b/help.c
> > @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)
> > 
> > if (SIMILAR_ENOUGH(best_similarity)) {
> > 
> > fprintf_ln(stderr,
> > 
> > -  Q_("\nDid you mean this?",
> > - "\nDid you mean one of these?",
> > +  Q_("\nThe most approaching command is",
> > + "\nThe most approaching commands are",
> > 
> >n));
> 
> For what it's worth, I find the new text harder to understand than the
> old text.
> 
> From the bug report:
> 
>   Now git says git: 'stahs' is not a git command. See 'git --help'.
>   Did you mean this?
> 
>   stash
> 
>   Git asked if i meant git stash. and i entered yes. and git
>   printed the character y infinite times.
> 
> If I'm reading that correctly, the problem is not that questions are
> alarming but that Git did not cope well with the answer.  When I try
> to reproduce it, I get

No, I don't think that the questions are alarming. The whole point is that Git 
no longer runs when the user enters its reply. In the case of the bug report, 
the user was unlucky to type in the name of the shell command `yes` because he 
was thinking that Git was still running interactively, due to the question at 
the end of the run.

So this patch series'aim is simply to get rid of asking questions just before 
exiting. Even if a question might seem more user friendly, it's insufficiently 
formal to indicate to the user that there's no point replying. The question 
was just a hint, and it should presented as such.

To be fair, I'm not accustomed enough to the code to know exactly in which 
cases the given strings are occurring (except here). All the patch series 
tries to tackle this at different levels. Maybe squashing them all would be 
better for understanding. 

> 
>   $ git stahs
>   WARNING: You called a Git command named 'stahs', which does not exist.
>   Continuing under the assumption that you meant 'stash'
>   in 5.0 seconds automatically...
> 
> which is much clearer.  After commenting out "[help] autocorrect = 50" in my
> ~/.config/git/config, I get
> 
>   $ git stahs
>   git: 'stahs' is not a git command. See 'git --help'.
> 
>   Did you mean this?
>   stash
> 
> which does seem improvable, at least for consistency with the
> autocorrect case.  For example, would something like
> 
>   $ git stahs
>   fatal: You called a Git command named 'stahs', which does not exist.
>   hint: Did you mean 'git stash'?
> 
> work better?  And the autocorrect case could say something like

Would adding a "hint:" prefix be enough to provide context? I don't think so. 
I'd prefer to be clearer on the objectives of the printed information, even at 
the risk of being clumsy.


>
>   $ git stahs
>   warning: You called a Git command named 'stahs', which does not exist.
>   warning: Continuing under the assumption that you meant 'stash'
>   warning: in 5.0 seconds automatically...
> 
> Is contact information for the bug reporter available so we can try out
> different wordings and see what works for them?

I guess so. The discussion on github is still open and only depends on the 
willingness of the reporter to reply.


> 
> Thanks and hope that helps,
> 

Re: [PATCH] i18n: remove i18n from tag reflog message

[Jean-Noël AVILA]

Le dimanche 30 avril 2017, 18:45:05 CEST Junio C Hamano a écrit :
> Jean-Noel Avila  writes:
> > The building of the reflog message is using strbuf, which is not
> > friendly with internationalization frameworks. No other reflog
> > messages are translated right now and switching all the messages to
> > i18n would require a major rework of the way the messages are built.
> 
> Thanks for spotting.  Before we declare that reflog messages are for
> i18n, we'd need to either drop (or redesign the implementation of)
> the "checkout -" feature, which relies on the exact phrasing of how
> reflog entries from "git checkout" looks like.
> 
> Will queue and merge down to 'master' quickly.
> 

I didn't know this "side effect". Maybe adding a test against it would be 
requiered. Unfortunately, I don't know enough of it.

Re: [L10N] Kickoff of translation for Git 2.13.0 round 1

[Jean-Noël AVILA]

Le dimanche 23 avril 2017, 10:49:27 CEST Jiang Xin a écrit :
> Hi,
> 
> Git v2.13.0-rc0 has been released, and it's time to start new round of git
> l10n. This time there are 96 updated messages need to be translated since
> last update:
> 
> l10n: git.pot: v2.13.0 round 1 (96 new, 37 removed)
> 
> Generate po/git.pot from v2.13.0-rc0 for git v2.13.0 l10n round 1.
> 
> Signed-off-by: Jiang Xin 
> 
> You can get it from the usual place:
> 
> https://github.com/git-l10n/git-po/
> 
> As how to update your XX.po and help to translate Git, please see
> "Updating a XX.po file" and other sections in “po/README" file.
> 
> --
> Jiang Xin


In builtin/tag.c, the newly added function 'create_reflog_msg' is a sentence 
lego that is not fitted for internationalization.

Thanks

Re: [PATCH v3 2/2] l10n: Add git-add.txt to localized man pages

[Jean-Noël AVILA]

Le dimanche 26 mars 2017, 15:56:55 CEST Junio C Hamano a écrit :
> Jean-Noël AVILA <jn.av...@free.fr> writes:
> > ... So I would
> > think the other way around: for those interested in translated the
> > documentation, some script would allow to checkout the git project inside
> > the gitman-l10n project (like a kind of library).
> > 
> > This would be mainly transparent for the git developers.
> 
> As long as the resulting layout would help all groups (1) developers
> who do not worry about documentation l10n (2) documentation i18n
> coordinator and transltors (3) those who build and ship binary
> packages, I personally am OK either way.
> 
> Having said that, I am not sure if I understand your "translators do
> not have a fixed version of git.git to work with and po4a cannot
> work well" as a real concern.  Wouldn't the l10n of documentation
> use a similar workflow as used for the translation of in-code
> strings we do in po/?  Namely, *.pot files are *NOT* updated by
> individual translators by picking up a random version of git.git and
> running xgettext.  Instead, i18n coordinator is the only person who
> runs xgettext to update *.pot for the upcoming release of Git being
> prepared, and then translators work off of that *.pot file.  Which
> means they do not have to worry about in-code strings that gets
> updated in the meantime; instead they work on a stable known
> snapshot of *.pot and wait for the next sync with i18n coordinator
> whose running of xgettext would update *.pot files with updated
> in-code strings.  Doesn't that workflow apply equally well for the
> documentation l10n?

Theoretically, this workflow should apply to the documentation, so that a 
version of the documentation can be cut at each release of git. I still have 
to convince po4a not to update the *.pot and *.po files each time it is run, 
while at the same time allow translators to produce the output file for 
proofreading.

Re: [PATCH v3 2/2] l10n: Add git-add.txt to localized man pages

[Jean-Noël AVILA]

Le mercredi 22 mars 2017 11:02:09 CET, vous avez écrit :
> Jean-Noël Avila <jn.av...@free.fr> writes:
> >> I am wondering if Documentation/po part should be a separate
> >> repository, with a dedicated i18n/l10n coordinator.  Would it make
> >> it easier for (1) those who write code and doc without knowing other
> >> languages, (2) those who update .pot and coordinate the l10n effort
> >> for the documentation and (3) those who translate them if we keep
> >> them in a single repository?
> > 
> > This is one of the points raised in the first RFC mail. Splitting this
> > part would help a lot manage the translations with their own workflow,
> > would not clutter the main repo with files not really needed for
> > packaging and would simplify dealing with the interaction with crowd
> > translation websites which can directly push translation content to a
> > git repo.
> 
> As I was in favor of splitting it out, I was trying to gauge what
> the downside of doing so would be, especially for those who are
> doing the translation work (it is obvious that it would help
> developers who are not translators, as nothing will change for them
> if we keep this new thing as a separate project).

There's one big downside of  this splitting. The gitman-l10n project would not 
be autonomous without the specific cloning at the particular place in the git 
project. po4a needs the original asciidoc files to perform the transclusion of 
the translated content into the structure of the documents. The setup that you 
are proposing would rule out simple CI checks and would make it complicated 
for the translators to set up their working copy and check the resulting man 
pages.

As I see it, there's the need for the Documentation folder to be contained in 
both project (while remaining the property of the git project). So I would 
think the other way around: for those interested in translated the 
documentation, some script would allow to checkout the git project inside the 
gitman-l10n project (like a kind of library).

This would be mainly transparent for the git developers.

> I'd prefer to start with the "optional gitman-l10n repository is
> checked out at Documentation/po only by convention" approach, before
> committing to bind it as a submodule.  Once we got comfortable with
> cooperating between these two projects, we do want to bind them
> using the submodule mechanism, but not before.

Obviously, my proposition would not allow to evolve towards such a setup, but 
is it really needed anyway ?

Re: [PATCH v3 2/2] l10n: Add git-add.txt to localized man pages

[Jean-Noël Avila]

Le 20/03/2017 à 23:05, Junio C Hamano a écrit :
> Jean-Noel Avila  writes:
>
>> Signed-off-by: Jean-Noel Avila 
>> ---
>>  Documentation/po/documentation.fr.po | 1095 
>> ++
>>  Documentation/po/documentation.pot   |  787 
>>  2 files changed, 1882 insertions(+)
>>  create mode 100644 Documentation/po/documentation.fr.po
>>  create mode 100644 Documentation/po/documentation.pot
> This sounds more like
>
> Subject: l10n: add fr localization for git-add manual pages
>
> to me.  The actual part of this patch that adds "git-add" is the
> addition of Documentation/po/documentation.pot, and from that point
> of view, this patch may want to be further split into two.

The generation of the documentation.pot and the documentation.fr.po is
already "virtually" done because that's what the po4a.conf file
describes in the previous patch. The point is that the po4a.conf file
for a minimum viable run of make implies that at least a language and a
file be described.

For documentation.po.fr, what is indeed added is the effective
translation. So I guess we could probably split the series differently,
with a po4a.conf and empty files, then the translation.

>
> But more importantly, aren't we essentially adding an equivalent of
>
>   cd Documentation && cat git-*.txt
>
> to our codebase?
>
> Surely we cannot avoid having a copy of all messages that are to be
> translated using msgid/msgstr based approach, and we already do so
> for end-user-facing in-program strings, but it just feels a bit too
> much having to carry a duplicate (and slightly a stale) copy of the
> entire documentation set around.  For N languages, we'll have an
> equivalent for N copies of the English text, in addition to the
> translated documentation.

True. The documentation source roughly weight 2.3MB, so each full
translation would add up 5MB to the working copy. More , that would also
generate another source of traffic for updates and questions from
readers, which may not be of interest for most developpers.

>
> I am wondering if Documentation/po part should be a separate
> repository, with a dedicated i18n/l10n coordinator.  Would it make
> it easier for (1) those who write code and doc without knowing other
> languages, (2) those who update .pot and coordinate the l10n effort
> for the documentation and (3) those who translate them if we keep
> them in a single repository?
This is one of the points raised in the first RFC mail. Splitting this
part would help a lot manage the translations with their own workflow,
would not clutter the main repo with files not really needed for
packaging and would simplify dealing with the interaction with crowd
translation websites which can directly push translation content to a
git repo.

There's still the question whether the secondary repo would copy the
original asciidocs and from there would manage them with po4a and then
the translated asciidoc sources would be pushed back to the main repo,
or if the main repo would still run the po4a, and only the translated po
files would be pushed back.

The first way would decouple the workflow and the tools used for
translating from the main repo. If po4a turns out to be too adventurous
for asciidoc (latest version tested with all the man pages, no visible
problem), that would not impact the main repo which could still benefit
from the job already done.

The later way would allow the main repo to keep an eye on how the
translation are up to date and decide to include them or not.

In any case, there would be a copy of the original asciidoc files to the
secondary repo, to be able to provide the source reference in the po
files and give context to the translators.

My personal preference would still go to the integration of po4a in the
main repo, but it isn't ready yet.

Thanks,

Re: [PATCH v2 1/2] l10n: Introduce framework for localizing man pages

[Jean-Noël AVILA]

Le 20/03/2017 à 09:10, Jean-Noël Avila a écrit :

> So I guess you made your trials on 14.04. So, switching to 14.04 on
> Travis would help, at least for this patch series, but that would help
> much for the (close) future.

 that *would not* help much for the (close) future.
<>

Re: [PATCH v2 1/2] l10n: Introduce framework for localizing man pages

[Jean-Noël Avila]

Le 20/03/2017 à 03:11, Junio C Hamano a écrit :
> Junio C Hamano  writes:
>
>> Travis seems to have failed.  Perhaps something like this is needed,
>> at least?
>>
>>  .travis.yml | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index 591cc57b80..719e5cdb00 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -20,6 +20,7 @@ addons:
>>  - language-pack-is
>>  - git-svn
>>  - apache2
>> +- po4a
>>  
>>  env:
>>global:
> Here is what I have for now on top of yours in an attempt to make it
> work with the public Travis, which is still not working X-<.
>
>   https://travis-ci.org/git/git/jobs/212839039
>
> shows how it breaks, which is somehow different from how it does not
> fail on a copy of Ubuntu I seem to be running, even though I seem to
> have the same 0.41-1ubuntu1 installed).  

Asciidoc support was added in 0.45, and was included Ubuntu 14.04 but is
not present in ubuntu 12.04. The latest version is 0.48.

So I guess you made your trials on 14.04. So, switching to 14.04 on
Travis would help, at least for this patch series, but that would help
much for the (close) future.

I'm trying to push for a release of a new version, because I stumbled
upon a bug on the support of include macros while extending the
translations to git-commit manpage. This bug is already fixed in master,
but no version has been published yet.


The bottom line is that using po4a brings mixed results, for now.

Re: [PATCH v2 1/2] l10n: Introduce framework for localizing man pages

[Jean-Noël AVILA]

Le samedi 18 mars 2017, 12:41:22 CET Junio C Hamano a écrit :
> Jean-Noel Avila  writes:
> > Providing git in localized version is a good step for general adoption
> > of the tool. But as of now, if one needs to refer to the manual pages,
> > they are still confronted to english. The aim is to provide
> > documentation to users in their own language.
> 
> Please outline how the end result looks like here.  Where are the
> localized man pages installed?  Do installers get to choose to build
> and install the localization for some but not all languages and if
> so how?  etc.
> 
> > signed-off-by: Jean-Noel Avila 
> 
> s/sign/Sign/;
> 
> > -man: man1 man5 man7
> > +man: man1 man5 man7 man_l10n
> 
> Hmmm, at least in the early days of the topic, I'd prefer that "make
> doc" and "make install" I need to run dozens of times a day from the
> toplevel not to require po4a.
> 
> Thanks.

Fair enough. 

Anyway, now I see  there's a take away from the discussion thread. Right now 
the man pages are tagged with the actual version of git, because the 
documentation is supposed to change at the same pace as the code. But that may 
not be true for translations, In this case, the automatic running of po4a will 
generate fuzzy matches which are not going to be used in the translated texts, 
leading to patchworked manpages, depending on the level of acceptance of 
untranslated entities.

If we want to freeze the translated manpages at a given version of git until a 
new version of the manpages is fully translated, we'll have to commit the 
translated .txt and force in some way the version to freeze (not using the 
generic asciidoc target of the Makefile).  But, that may drag the version of 
translations far behind the original if translation is stalled.

Or maybe people will not be so upset by mixed language manpages when the 
translation is lagging, but will prefer to have a "best available translation" 
of up-to-date pages. Plus that would be managed automatically by po4a's level 
of translation threshold to effectively generate a translated man page as long 
as the untranslated parts are still sparse in the mixed-up text.

For now, I keep this last option.

Re: [PATCH] l10n: add framework for localizing the manpages

[Jean-Noël Avila]

Le 14/03/2017 à 22:00, Ævar Arnfjörð Bjarmason a écrit :
> On Mon, Mar 13, 2017 at 1:01 AM, Junio C Hamano  wrote:
>> Jean-Noel Avila  writes:
> Jean: Comments on the patch:
>
> - Firstly thanks for working on this. When I hacked up the initial po
> support in v1.7.8-rc2-1-g5e9637c629 I always meant to try out po4a,
> but never got around to it. It's much easier than I thought.

Well, that's only the simplest setup I could come up with :-). I'm
discovering the tool and it seems that can go quite hairy, depending on
where we want to go.

> - Consider submitting a more minimal patch that doesn't have the giant
> fr.po (or just some minor cut version) as the tip of the series, to
> make this easier to review

OK. Will split in po4a.conf + Makefile changes, then pot and po files.
The point is that as long as the po files are not translated at a
minimum level, po4a does not generate the target files. Right now, the
threshold is 80% of translated strings (no fuzzy).

> - The git-add.txt file is hardcoded in po4a.conf, won't this file need
> to be generated in some final version of this series?

If all the translation string are harvested automatically from the
source files, the resulting po file will be huge. For the moment, I
prefered to manually select the files and check that po4a behaves correctly.

Re: [PATCH] l10n: add framework for localizing the manpages

[Jean-Noël Avila]

Le 13/03/2017 à 01:01, Junio C Hamano a écrit :
> +#. type: Plain text
>> +#: git-add.txt:15
>> +#, no-wrap
>> +msgid ""
>> +"'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive 
>> | -i] [--patch | -p]\n"
>> +"\t  [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]]\n"
>> +"\t  [--intent-to-add | -N] [--refresh] [--ignore-errors] 
>> [--ignore-missing]\n"
>> +"\t  [--chmod=(+|-)x] [--] [...]\n"
>> +msgstr ""
>> +"'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]\n"
>> +"\t  [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]]\n"
>> +"\t  [--intent-to-add | -N] [--refresh] [--ignore-errors] 
>> [--ignore-missing]\n"
>> +"\t  [--] [...]\n"
> This shows that even after adding just _one_ new option to the
> command, the whole thing need to be re-translated (the SYNOPSIS
> section may be a bad example, as not much is subject to i18n,
> though).  If each paragraph of the description section becomes a
> single string that need to be re-translated, as we can see below, I
> am not sure if it really helps the translators.  A mere single
> rephrasing of a word in a large paragraph would have to result in
> the entire paragraph to be translated again?

I'm not sure to clearly understand your point: if there is the
introduction of a new option, there is a need to update the translation
for sure.

 

The use of po files introduces tools to automatically mark the
paragraphs that need to be retranslated or if the translation was near
enough to be reviewed (entries are translated with the approaching
translation and marked as "fuzzy"). Using po, it is also possible to use
translation memories (such as the po file for the programs).

 

Now the choice of segmentation of the text might be discussed, but
usually, the translators prefer to keep a paragraph level, because
that's the range that can span an idea and allows shuffling the
sentences if needed. If a finer grain can be used, that's usually at the
step of writing the original text that the decision is taken to ease the
translation burden.

>> +#. type: Title -
>> +#: git-add.txt:17
>> +#, no-wrap
>> +msgid "DESCRIPTION"
>> +msgstr "DESCRIPTION"
>> +
>> +#
>> +#. type: Plain text
>> +#: git-add.txt:24
>> +msgid ""
>> +"This command updates the index using the current content found in the "
>> +"working tree, to prepare the content staged for the next commit.  It "
>> +"typically adds the current content of existing paths as a whole, but with "
>> +"some options it can also be used to add content with only part of the "
>> +"changes made to the working tree files applied, or remove paths that do 
>> not "
>> +"exist in the working tree anymore."
>> +msgstr ""
>> +"Cette commande met à jour l'index en utilisant le contenu actuel trouvé 
>> dans "
>> +"la copie de travail, pour préparer le contenu de la prochaine validation. "
>> +"Typiquement, elle ajoute intégralement le contenu actuel des chemins "
>> +"existant, mais peut aussi n'ajouter que certaines parties des 
>> modifications "
>> +"au moyen d'options ou soustraire certains chemins qui n'existent plus dans 
>> "
>> +"la copie de travail."
> It almost makes me suggest that a totally different approach might
> be more manageable.  For example, we can pick one version of a
> source file (say, "v2.12.0:Documentation/git-add.txt"), have it
> fully translated to the target languages, _and_ make it a convention
> to record the original blob object name at the end of the translated
> file.  Perhaps "Documentation/l10n/fr/git-add.txt" may record the
> result of such translation effort.
>
> And then, when somebody wants to update the translation for v2.13.0,
> perhaps 
>
> git diff --color-words $old_blob v2.13.0:Documentation/git-add.txt
>
> (where $old_blob is taken from Documentation/l10n/fr/git-add.txt)
> can be examined and then Documentation/l10n/fr/git-add.txt can be
> adjusted to match the changes between the two versions.  After that,
> update the "source" blob object name in the translation.

That's the whole point of using po files which embed the management of
change (the original strings) independently from git, compared to
diffing between revisions of the original file and applying the
translations of the changes into the translated ones.



>
> So, I dunno.  I like the goal and appreciate the effort to get to
> that goal.  I am not sure what the best approach would be and the
> sample translation mechanism I see in this patch makes me doubt that
> it is the best approach.

That may sound like an authority argument, the po4a was specifically
developped and used for the translation of man pages (in debian for
instance), with success.

 

Anyway, we can manage the po4a workflow outside of the git repo and only
push the end results (the asciidoc files). The initial proposition was
also aimed at putting in common the tools for other translators (CC'ed),
to the expense of yet another dependency.


Thanks

Re: [PATCH] l10n: add framework for localizing the manpages

[Jean-Noël AVILA]

This patch is only a preview and a request for comment. The tool used to 
perform the localization of manpages is po4a (po for anything). This tool 
digests the asciidoc source files and writes a pot file, and then merges back 
the po files into translated asciidoc files, for further processing.

The choice of this workflow is driven by two concerns: manage the tracking of 
the changes in the original files and provide the translators with a format of 
file that they already use. Moreover, I plan to upload the po files to web 
translation platforms such as transifex or weblate to take advantage of crowd 
translation.

In this patch, only one manpage is generated for the git-add command in 
french. po4a already supports extending to other languages, and merges all the 
strings from multiple source manpages into one big pot file. In the next 
version, two files will be included so that the sharing of common strings is 
shown. There are some enhancement needed for better support of other output 
formats.

One problem with this setup is that we don't know before hand which files will 
be generated from the po files and the source files. This depends on the level 
of completion of translation for each language and each target file. To 
circumvent this, the makefile calls itself recursively after running po4a, so 
that the generated files can be enumerated in the downstream targets.

It would be understandable that the git devel list would not like to be 
spammed by the traffic generated by this new activity.If the present 
proposition 
is accepted,  I'm open to any modus operandi for submitting the changes.

Thanks for reading.

Re: [PATCH 1/6] i18n: commit: mark message for translation

[Jean-Noël AVILA]

Signed-off-by: Vasco Almeida 
Signed-off-by: Jean-Noel Avila 
---

Instead of distillating change requests, I'd better do it by myself. Here is 
the reworked version of the patch.

 diff.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/diff.c b/diff.c
index c6da383..494f723 100644
--- a/diff.c
+++ b/diff.c
@@ -55,6 +55,11 @@ static char diff_colors[][COLOR_MAXLEN] = {
GIT_COLOR_NORMAL,   /* FUNCINFO */
 };
 
+static NORETURN void die_want_option(const char *option_name)
+{
+   die(_("option '%s' requires a value"), option_name);
+}
+
 static int parse_diff_color_slot(const char *var)
 {
if (!strcasecmp(var, "context") || !strcasecmp(var, "plain"))
@@ -3325,7 +3330,7 @@ void diff_setup_done(struct diff_options *options)
if (options->output_format & DIFF_FORMAT_NO_OUTPUT)
count++;
if (count > 1)
-   die("--name-only, --name-status, --check and -s are mutually 
exclusive");
+   die(_("--name-only, --name-status, --check and -s are mutually 
exclusive"));
 
/*
 * Most of the time we can say "there are changes"
@@ -3521,7 +3526,7 @@ static int stat_opt(struct diff_options *options, const 
char **av)
if (*arg == '=')
width = strtoul(arg + 1, , 10);
else if (!*arg && !av[1])
-   die("Option '--stat-width' requires a value");
+   die_want_option("--stat-width");
else if (!*arg) {
width = strtoul(av[1], , 10);
argcount = 2;
@@ -3530,7 +3535,7 @@ static int stat_opt(struct diff_options *options, const 
char **av)
if (*arg == '=')
name_width = strtoul(arg + 1, , 10);
else if (!*arg && !av[1])
-   die("Option '--stat-name-width' requires a 
value");
+   die_want_option("--stat-name-width");
else if (!*arg) {
name_width = strtoul(av[1], , 10);
argcount = 2;
@@ -3539,7 +3544,7 @@ static int stat_opt(struct diff_options *options, const 
char **av)
if (*arg == '=')
graph_width = strtoul(arg + 1, , 10);
else if (!*arg && !av[1])
-   die("Option '--stat-graph-width' requires a 
value");
+   die_want_option("--stat-graph-width");
else if (!*arg) {
graph_width = strtoul(av[1], , 10);
argcount = 2;
@@ -3548,7 +3553,7 @@ static int stat_opt(struct diff_options *options, const 
char **av)
if (*arg == '=')
count = strtoul(arg + 1, , 10);
else if (!*arg && !av[1])
-   die("Option '--stat-count' requires a value");
+   die_want_option("--stat-count");
else if (!*arg) {
count = strtoul(av[1], , 10);
argcount = 2;
-- 
2.10.0

Re: [PATCH 1/6] i18n: commit: mark message for translation

[Jean-Noël AVILA]

On lundi 19 septembre 2016 10:54:37 CEST Junio C Hamano wrote:
> I am responding to 1/6, as the series lacked a cover letter, but all
> of them looked good.
> 
> Thanks.

Maybe 3/6 would have benefited from some code factorization. But that's ok for 
a few more sentences.

Thanks.

Re: [PATCH v2 09/14] i18n: notes: mark error messages for translation

[Jean-Noël AVILA]

On mardi 13 septembre 2016 16:35:05 CEST Vasco Almeida wrote:
> A Seg, 12-09-2016 às 14:23 +0200, Jean-Noël Avila escreveu:
> > Not sure this one will be easy to localize. The verb is passed as a
> > parameter : see line 366 "list", line 426 "add", line 517 "copy",
> > line
> > 658 "show", line 816 "merge", line 908 "remove" or line 595 with
> > argv[0].
> > 
> > If all the verbs are real subcommands, then the translators should be
> > warned that this is some english twisting, but that they need to
> > refer
> > to the subcommand on the command line.
> 
> Yes, these verbs are git notes subcommands. I will add a Translators
> comment to it explaining so. Or we can unfold that error messages like
> 
> if (!strcmp(subcommand, "add")
>   die(_("Refusing to add notes in %s (outside of refs/notes/)"),
> ref);
> elseif ...
> 
> else
>   die(_("Refusing to %s notes in %s (outside of refs/notes/)"),
> subcommand, ref);

This would be counter productive to use the inject strings as keys just to 
test them just after.

> 
> This is more verbose but translations would benefit from it being more
> natural. What do we prefer: (1) concise source and a little unnatural
> translations or (2) verbose code and natural translations?
> 
> Compare, imaging that English is a target translation language, the
> user would read:
> "Refusing to do add of notes in /path [...]" (1)
> "Refusing do add notes in /path [...]" (2)

Having one sentence per action is cumbersome, but avoiding sentence lego is 
mandatory for proper i18n. How about  just adding quotes around the subcommand 
and warn translators ? 

Re: [PATCH v2 12/14] i18n: show-branch: mark error messages for translation

[Jean-Noël AVILA]

On lundi 12 septembre 2016 10:02:54 CEST Junio C Hamano wrote:
> Jean-Noël Avila <jn.av...@free.fr> writes:
> > Le 12/09/2016 à 13:30, Vasco Almeida a écrit :
> >>if (MAX_REVS < reflog)
> >> 
> >> -  die("Only %d entries can be shown at one time.",
> >> +  die("only %d entries can be shown at one time.",
> >> 
> >>MAX_REVS);
> > 
> > Wouldn't you i18n this one too, with plural form?
> 
> I would think this one is OK in practice for the same reason as 7/14

I would think the contrary for the same reason as 14/14 

We don't know the actual value of MAX_REVS at the time we translate, and 
plural forms can be quite different depending on its value. See for instance 
polish:

https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html

Of course, too bad, we only use one of the forms but I don't see any 
alternative.

Thanks,

JN

Re: [PATCH v2 09/14] i18n: notes: mark error messages for translation

[Jean-Noël Avila]

Le 12/09/2016 à 13:29, Vasco Almeida a écrit :
> Signed-off-by: Vasco Almeida <vascomalme...@sapo.pt>
> ---
>  builtin/notes.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/builtin/notes.c b/builtin/notes.c
> index f848b89..abacae2 100644
> --- a/builtin/notes.c
> +++ b/builtin/notes.c
> @@ -340,7 +340,7 @@ static struct notes_tree *init_notes_check(const char 
> *subcommand,
>  
>   ref = (flags & NOTES_INIT_WRITABLE) ? t->update_ref : t->ref;
>   if (!starts_with(ref, "refs/notes/"))
> - die("Refusing to %s notes in %s (outside of refs/notes/)",
> + die(_("Refusing to %s notes in %s (outside of refs/notes/)"),
>   subcommand, ref);
>   return t;
>  }

Not sure this one will be easy to localize. The verb is passed as a
parameter : see line 366 "list", line 426 "add", line 517 "copy", line
658 "show", line 816 "merge", line 908 "remove" or line 595 with argv[0].

If all the verbs are real subcommands, then the translators should be
warned that this is some english twisting, but that they need to refer
to the subcommand on the command line.

Otherwise,

Acked-by: Jean-Noël Avila <jean-noel.av...@free.fr>

JN

Re: [PATCH v2 12/14] i18n: show-branch: mark error messages for translation

[Jean-Noël Avila]

Le 12/09/2016 à 13:30, Vasco Almeida a écrit :
>   if (MAX_REVS < reflog)
> - die("Only %d entries can be shown at one time.",
> + die("only %d entries can be shown at one time.",
>   MAX_REVS);

Wouldn't you i18n this one too, with plural form?


JN

Re: [PATCH v2 07/14] i18n: merge-recursive: mark error messages for translation

[Jean-Noël Avila]

Hi,

Le 12/09/2016 à 13:29, Vasco Almeida a écrit :
> - warning("Cannot handle more than %d bases. "
> - "Ignoring %s.",
> + warning(_("cannot handle more than %d bases. "
> +   "Ignoring %s."),
>   (int)ARRAY_SIZE(bases)-1, argv[i]);
>   }

This one is also missing the plural form.

Thanks,

JN

Re: [PATCH 04/13] i18n: blame: mark error messages for translation

[Jean-Noël AVILA]

On mercredi 7 septembre 2016 14:49:08 CEST Vasco Almeida wrote:
> Mark error messages for translation passed to die() function.
> Change "Cannot" to lowercase following the usual style.
> 
> Reflect changes to test by using test_i18ngrep.
> 
> Signed-off-by: Vasco Almeida 
> ---
>  builtin/blame.c   | 12 ++--
>  t/t8003-blame-corner-cases.sh |  4 ++--
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/builtin/blame.c b/builtin/blame.c
> index a5bbf91..3fee197 100644
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -2601,7 +2601,7 @@ int cmd_blame(int argc, const char **argv, const char
> *prefix)
> 
>   if (incremental || (output_option & OUTPUT_PORCELAIN)) {
>   if (show_progress > 0)
> - die("--progress can't be used with --incremental or 
> porcelain 
formats");
> + die(_("--progress can't be used with --incremental or 
> porcelain
> formats")); show_progress = 0;
>   } else if (show_progress < 0)
>   show_progress = isatty(2);
> @@ -2727,7 +2727,7 @@ int cmd_blame(int argc, const char **argv, const char
> *prefix) sb.commits.compare = compare_commits_by_commit_date;
>   }
>   else if (contents_from)
> - die("--contents and --reverse do not blend well.");
> + die(_("--contents and --reverse do not blend well."));
>   else {
>   final_commit_name = prepare_initial();
>   sb.commits.compare = compare_commits_by_reverse_commit_date;
> @@ -2747,12 +2747,12 @@ int cmd_blame(int argc, const char **argv, const
> char *prefix) add_pending_object(, &(sb.final->object), ":");
>   }
>   else if (contents_from)
> - die("Cannot use --contents with final commit object name");
> + die(_("cannot use --contents with final commit object name"));
> 
>   if (reverse && revs.first_parent_only) {
>   final_commit = find_single_final(sb.revs, NULL);
>   if (!final_commit)
> - die("--reverse and --first-parent together require 
> specified latest
> commit"); +   die(_("--reverse and --first-parent together 
> require
> specified latest commit")); }
> 
>   /*
> @@ -2779,7 +2779,7 @@ int cmd_blame(int argc, const char **argv, const char
> *prefix) }
> 
>   if (oidcmp(>object.oid, >object.oid))
> - die("--reverse --first-parent together require range 
> along first-
parent
> chain"); +die(_("--reverse --first-parent together 
> require range along
> first-parent chain")); }
> 
>   if (is_null_oid(>object.oid)) {
> @@ -2820,7 +2820,7 @@ int cmd_blame(int argc, const char **argv, const char
> *prefix) , , sb.path))
>   usage(blame_usage);
>   if (lno < top || ((lno || bottom) && lno < bottom))
> - die("file %s has only %lu lines", path, lno);
> + die(_("file %s has only %lu lines"), path, lno);

Here a plural version is needed.

>   if (bottom < 1)
>   bottom = 1;
>   if (top < 1)
> diff --git a/t/t8003-blame-corner-cases.sh b/t/t8003-blame-corner-cases.sh
> index e48370d..661f9d4 100755
> --- a/t/t8003-blame-corner-cases.sh
> +++ b/t/t8003-blame-corner-cases.sh
> @@ -212,12 +212,12 @@ EOF
> 
>  test_expect_success 'blame -L with invalid start' '
>   test_must_fail git blame -L5 tres 2>errors &&
> - grep "has only 2 lines" errors
> + test_i18ngrep "has only 2 lines" errors
>  '
> 
>  test_expect_success 'blame -L with invalid end' '
>   test_must_fail git blame -L1,5 tres 2>errors &&
> - grep "has only 2 lines" errors
> + test_i18ngrep "has only 2 lines" errors
>  '
> 
>  test_expect_success 'blame parses  part of -L' '

Request for advice: visual diffing kicad EDA schematics

[Jean-Noël AVILA]

Hi all,

I would like to be able to visually see the differences between two versions 
of schematic sheets of a kicad project.

Kicad file format is ascii based, which allows to generate text diff between 
versions of schematic files. However, except for adding and removing 
components, when the modified lines refer to drawing primitives, it isn't 
obvious what has changed.

Schematic file format differs from text picture formats (e.g. svg, pnm) in that 
the schematics is made of an assembly of lines, texts and references to 
electronic parts whose symbols are stored in external library files. Hopefully, 
for each project, Kicad stores a local cache library of all the parts used in 
the project, so the project directory is self contained.

But of course, to be able to plot a schematic sheet, you need the schematic 
sheet file and the project cache library at the same version, which defeats the 
custom diff mechanics of git that can be used for plain pictures.

My questions:
 * Does this sound familiar to any body ?
 * Is there some hook in git to deal with this or will I have to roll my own 
utility? In which case, would you advise to use git porcelain or libgit binded 
to a favorite script language?

Thanks in advance for all information.

Jean-Noël

Re: [L10N] Kickoff of translation for Git 2.10.0 round 1

[Jean-Noël AVILA]

On mardi 23 août 2016 08:58:55 CEST Junio C Hamano wrote:

> > Let's cut it like this : first ten are literally translated, the following
> > ones fall back to a general rule.
> 
> I actually once wrote "It is rare to squash dozens of commits into
> one, so the first ten or dozen messages that spell the ordinals out
> may be a good thing for readability", in the message you are
> responding to, before realizing that the messages actually say
> "1st", "2nd", etc., not "first", "second", etc., and scrapped that
> part of the response.  I do not really see much point in forcing the
> first ten to be translated differently.

In fact, taking some advance on the patch, I made the translations and used 
full words in the translated language.
By majority of repliers, let's just use a single sentence for each case "use" 
or "skip". 

Will rerun the patch set.

JN
--
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] Kickoff of translation for Git 2.10.0 round 1

[Jean-Noël AVILA]

On samedi 20 août 2016 11:03:00 CEST Junio C Hamano wrote:
> Jean-Noël AVILA <jn.av...@free.fr> writes:
> > 1.  In config.c, the changes to the function die_bad_number tried to
> > flatten the translated strings (no message building logic). I think it
> > went too far, and the reason of the failure can be factorized so that we
> > don't have to retranslate each time. I might be wrong on this one, but I
> > have no example of language where we would need differentiated error
> > reasons.
> 
> I do not have a strong opinion on this one.  I think it is an
> attempt to avoid language-lego.

No problem with the changes for blob, files, command line. It's just about 
dividing by two the number of strings to translate by factorizing "out of 
range" and "invalid unit", which are invariable anyway. 

> 
> > 2.  in sequencer.c, there is a mistake in the original string to translate
> > "Cannot revert during a another revert"
> 
> This should be corrected. Thanks for spotting.

I also spotted a missing capitals. Will propose a patch.

> 
> > 3. git-rebase--interactive, in this_nth_commit_message and
> > skip_nth_commit_message are not localizable,
> 
> As the "TRANSLATORS" comment alludes to, "This is the Nth thing" can
> be rephrased to "This is the thing N" or "This is the thing #N"
> easily, and if that form without ordinal is acceptable for many
> languages, we should say that it is also OK in C-locale without
> translation.  So I agree that the recent change was pointless (even
> though the result may be localizable).
> 
> In an ideal world, I would imagine that this would be done by using
> Q_("This is the first thing", "This is the thing #%d", nth) aka
> ngettext, but
> 
> (1) I haven't seen ngettext used from shell scripts; and
> 

There's a use_ngettext macro

> (2) I do not think po files are set up to express "for this
> message, this language has 4 variants and here are the local
> rules to decide which one to use depending on the number,
> but the rules apply only to this message".  The Plural-Forms
> rule [*1*] seems to be global to a .po file, unfortunately.
> 


> so I do not think we cannot do it with ngettext().
> 

Let's cut it like this : first ten are literally translated, the following ones 
fall back to a general rule. All languages are treated equally. With more than 
10 squashed commit, you no longer really care if the numbering is pedantically 
correct.

> [Reference]
> 
> *1*
> https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Plural-> 
> forms.html


--
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] Kickoff of translation for Git 2.10.0 round 1

[Jean-Noël AVILA]

Hi all,

Before anyone tries to localize this round, I'd like to make some preliminary 
comments:

1.  In config.c, the changes to the function die_bad_number tried to flatten 
the 
translated strings (no message building logic). I think it went too far, and 
the reason of the failure can be factorized so that we don't have to 
retranslate each time. I might be wrong on this one, but I have no example of 
language where we would need differentiated error reasons.

2.  in sequencer.c, there is a mistake in the original string to translate 
"Cannot revert during a another revert"

3. git-rebase--interactive, in this_nth_commit_message and 
skip_nth_commit_message are not localizable, because the logic of declination 
of numeral attributes is in the code and is really oriented towards English 
and doesn't make sense for other languages (with 28 strings to translate !). 
In this case, I would suggest to step back and just have a single string per 
function.

If translators can quickly agree on these issues and maybe others I haven't 
seen, I can prepare a patch for review this weekend.

BR

Jean-Noël (french translation)



--
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: [BUG] can not escape sharps in git config file

[Jean-Noël Avila]

My mistake, sorry for the noise,

JFTR:

 * only double quotes can fully escape a string (it is safer to enclose
the whole value in double quotes)
 * backslashes have to be doubled because they are interpreted by git

So

[filter "kicad_sch"]
clean = "sed -E 's/#(PWR|FLG)[0-9]+/#\\1?/'"
smudge = cat

JN
--
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: [BUG] can not escape sharps in git config file

[Jean-Noël Avila]

Forgot to add:

± git --version
git version 2.8.3
--
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

[BUG] can not escape sharps in git config file

[Jean-Noël Avila]

Hi everyone,

I stumbled on this:

config file:

[filter "kicad_sch"]
clean = sed -E 's/#(PWR|FLG)[0-9]+/#\1?/'
smudge = cat


Then in the shell:

± git add -u
sed -E 's/: 1: sed -E 's/: Syntax error: Unterminated quoted string
error: external filter sed -E 's/ failed 2
error: external filter sed -E 's/ failed

It seems that the  # is used for end-of-line comments and can not be
escaped, even in quotes or backslash.

JN


--
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 v2 4/7] i18n: builtin/pull.c: mark strings for translation

[Jean-Noël Avila]

Le 12/04/2016 11:52, Duy Nguyen a écrit :
>
> Ex-translator speaking. Context is important. If it's me, I would even
> go as far as marking the whole line translatable just to give more
> context (it's mostly just copy and translate a few words then). But
> then again, I was half developer half translator and may see things a
> bit differently. Maybe _("") is a good balance.

I second this opinion. Translating a single word without context is
generally not advised. The english word might come up in different
situations with different grammatical forms for the translated version.

Adding the brackets provides enough context, as long as the string is
always used in the same semantic field, describing the command line. I
just don't know how much that helps reducing the amount of translated
strings.


JN
--
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] Fixed grammar mistake in the french localization

[Jean-Noël AVILA]

Cherry-picked, fixed and PR to Jiang Xin

JN
--
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: Git mascot

[Jean-Noël AVILA]

Le vendredi 15 avril 2016, 11:41:52 Christian Howe a écrit :
> There has been talk of a git mascot a while back in 2005. Some people
> mentioned a fish or a turtle. Since all the great open source projects
> like Linux or RethinkDB have a cute mascot, git definitely needs one
> as well. A mascot gives people a recognizable persona towards which
> they can direct their unbounded love for the project. It'd even be
> good if a plush doll of this mascot could eventually be created for
> people to physically express their love of git through cuddling and
> hugging.

No graphical skills at all, but...

I would go for a granny who is knitting, making a great sock. Not sure, this 
would feel modern, but at least, she could tell us some stories from the 
trenches...

Cheers,

JN



--
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] fr.po: Fix "uptream" typo

[Jean-Noël AVILA]

Le mercredi 21 octobre 2015, 15:25:59 Thomas Schneider a écrit :
> Signed-off-by: Thomas Schneider 
> ---
>  po/fr.po | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/po/fr.po b/po/fr.po
> index 581167f..71c4b54 100644
> --- a/po/fr.po
> +++ b/po/fr.po
> @@ -8862,7 +8862,7 @@ msgstr ""
>  "Si vous souhaitez indiquer l'information de suivi distant pour cette "
>  "branche, vous pouvez le faire avec :\n"
>  "\n"
> -"git branch --set-uptream-to=%s/ %s\n"
> +"git branch --set-upstream-to=%s/ %s\n"
> 
>  #: builtin/pull.c:476
>  #, c-format

Thanks,

It will be included in the next l10n update.

Jean-Noël
--
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 1/3] Add Travis CI support

[Jean-Noël Avila]

Le 15/10/2015 00:52, Lars Schneider a écrit :
> On 12 Oct 2015, at 22:20, Matthieu Moy  wrote:
>
>> larsxschnei...@gmail.com writes:
>>
>>> --- /dev/null
>>> +++ b/.travis.yml
>>> @@ -0,0 +1,46 @@
>>> +language: c
>>> +
>>> +os:
>>> +  - linux
>>> +  - osx
>>> +
>>> +compiler:
>>> +  - clang
>>> +  - gcc
>>> +
>>> +before_install:
>>> +  - >
>>> +export GIT_TEST_OPTS=" --quiet";
>>> +case "${TRAVIS_OS_NAME:-linux}" in
>>> +linux)
>>> +  wget -q https://package.perforce.com/perforce.pubkey -O - \
>>> +| sudo apt-key add -
>>> +  echo 'deb http://package.perforce.com/apt/ubuntu precise release' \
>>> +| sudo tee -a /etc/apt/sources.list
>>> +  wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add -
>>> +  echo 'deb https://packagecloud.io/github/git-lfs/debian/ jessie 
>>> main' \
>>> +| sudo tee -a /etc/apt/sources.list
>>> +  sudo apt-get update -qq
>>> +  sudo apt-get install -y apt-transport-https
>>> +  sudo apt-get install perforce-server git-lfs
>> Sorry if this has been discussed already, but do you really need these
>> "sudo" calls?
>>
>> They trigger builds on the legacy Travis CI infrastructure:
>>
>>  
>> http://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice_medium=banner_campaign=legacy-upgrade
>>
>> No big deal, but getting rid of sudo would be cool, and documenting why
>> it can't easily be done in commit message and/or comments would be nice
>> otherwise.
> I would like to get rid of the "sudo" calls, too. Unfortunately I wasn't able 
> to achieve this so far because these packages are not white listed on Travis 
> CI (see Jean-Noël answer in this thread). I tried to download and install the 
> *.deb files manually using dpkg without luck. Any idea or hint?
> Nevertheless I don't think this is a problem as Travis CI states that "sudo 
> isn't possible (__right now__)" on the new infrastructure. They need to find 
> a solutions because I believe many projects will run into this issue...
> http://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice_medium=banner_campaign=legacy-upgrade#Using-sudo-isn%E2%80%99t-possible-(right-now)
>
> - Lars


There's another hope. The requirements can be installed in the user's
HOME and cached between builds. In this case, no need for sudo.
Obviously, that rules out using apt and dpkg.

Jean-Noël
--
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 1/3] Add Travis CI support

[Jean-Noël Avila]

Le 11/10/2015 19:55, larsxschnei...@gmail.com a écrit :
> +
> +before_script: make
> +
> +script: make --quiet test

Travis can be used in container mode but that would need getting rid of
"sudo" command and only installing from white-listed sources
(https://github.com/travis-ci/apt-source-whitelist/blob/master/ubuntu.json)

Anyway, even within the present VM mode, 1.5 cores are available, so it
makes sense to add "-j2" to every make commands.

 

--
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] Kickoff of translation for Git 2.6.0 round 1

[Jean-Noël AVILA]

Le samedi 5 septembre 2015, 10:17:54 Jiang Xin a écrit :
> Hi,
> 
> Git v2.6.0-rc0 has been released, and it's time to start new round of git
> l10n. This time there are 123 updated messages need to be translated since
> last update:
> 
> l10n: git.pot: v2.6.0 round 1 (123 new, 41 removed)
> 
> Generate po/git.pot from v2.6.0-rc0-24-gec371ff for git v2.6.0 l10n
> round 1.
> 
> Signed-off-by: Jiang Xin 
> 
> You can get it from the usual place:
> 
> https://github.com/git-l10n/git-po/
> 
> As how to update your XX.po and help to translate Git, please see
> "Updating a XX.po file" and other sections in “po/README" file.
> 
> --
> Jiang Xin


Some new strings are not consistent with the actual set.

For instance, in the "Could not ..." strings were all with capitals, and some 
new ones are not. Last time, I remarked strings which were almost exactly the 
same (only difference was a final dot, if I remember). Some help strings were 
mixing different styles.

Some strings may be difficult to translate in some languages. We need a first 
set of commits to correct these errors, before updating the translations. In a 
longer term, a style/i18n guideline and checker would be very useful.

My two cents.

Jean-Noel
--
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: Internationalization and yes/no prompts

[Jean-Noël Avila]

Le 24/02/2015 21:32, Junio C Hamano a écrit :
 - explicitly put y/n in the message. Translaters should be warned to
 let y/n,
 This may be suboptimal from the end-user's point of view, but it is
 the least risky of breaking anything.

 And it is way better than the status quo.



I can push a small update for this one.

The yes string could be translated in builtin/clean.c

Are there other places where a translated part asks explicitly for a
yes/no reply? It is not clear from the content of the po file.

BR

Jean-Noël
--
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

Tagging a branch as not fitted for branching ?

[Jean-Noël Avila]

Most manuals on git state that it is bad practice to push -f a branch 
after have meddled with its history, because this would risk to upset 
the repositories of the coworkers. On the other hand, some workflows use 
branches to propose modifications, and need some rewritting of the 
history after some review steps. In this case, the branch should only be 
seen as a mere pile of patches. Having this two-sided discourse is often 
misunderstood by casual git users.


The proposed solution would be to be able to flag the branches with a 
special tag not fitted for branching that a collaborator could use 
when pushing it. This tag would be passed on to any pulled remote. When 
another collaborator would then issue a git checkout -b, the command 
would fail with a warning message, unless forced with '-f'.


Is this feature already present? If not, would it be of any interest?

Best regards,

Jean-Noël AVILA
--
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: [GIT PULL] hotfix on fr.po for the maint branch

[Jean-Noël AVILA]

Le vendredi 30 août 2013 09:54:59 Junio C Hamano a écrit :
 Jiang Xin worldhello@gmail.com writes:
  Please merge this commit to the maint branch.
  
  The following changes since commit 
e230c568c4b9a991e3175e5f65171a566fd8e39c:
Git 1.8.4 (2013-08-23 11:49:46 -0700)
  
  are available in the git repository at:
git://github.com/git-l10n/git-po master
  
  for you to fetch changes up to 21860882c8782771e99aa68fab6e365c628ff39d:
l10n: fr.po: hotfix for commit 6b388fc (2013-08-30 16:59:29 +0800)
  
  
  
  Sebastien Helleu (1):
l10n: fr.po: hotfix for commit 6b388fc
 
 Hmph, what happened that requires a hotfix to message strings?

Well, as the author of the first commit,, I must say that the quality was not 
good. But it became visible and hooked up a reviewer only when it was promoted 
to stable version...

There are some strings that do not make sense in the usage pages, a missing %s 
in one. Agreed that applying this patch does not solve a critical 
issue, but 
it is low risk.

 
   po/TEAMS |1 +
   po/fr.po | 1591
   ++ 2 files
   changed, 874 insertions(+), 718 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

Re: Off-line deverloper workflow?

[Jean-Noël Avila]

Le 27/06/2013 14:46, Woody Wu a écrit :

Hi,

I have a colleague who has to left our office for three month, but still
need to work on the project which is hosted on our in-office git
repository. Problem is that our company has firewall, it's not possible
or not allowed to access the company LAN outside the building.  So I
want to ask you expert, can you suggest a best practice of git workflow
that suitable to my situation?

Thanks in advance.

-woody

--
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


For a short time, I had the same issue. We came up using git bundle to 
bundle changes and exchange them via email.


The setup was to work in two separate branches. The roaming developper 
started a new branch when leaving. After some work, she sent the commits 
on her branch as a bundle file. The origin merged the branch extracted 
from the developper's bundle and sent back the bundle of the changes on 
origin since the last merge.


No doubt that both side need to understand well the workflow of 
fetch/merge. Bundle files can be encrypted for better security.


Hope this helps.

JN
--
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

[PATCH] t9902: Instruct git-completion.bash about a test mode

[Jean-Noël AVILA]

In test mode, git completion should propose commands only if they
belong to the list of authorized commands.

Signed-off-by: Jean-Noel Avila jn.av...@free.fr
---

Better show some code than try to explain. Here is what I mean by
filter the output git help -a. 

 contrib/completion/git-completion.bash | 16 +++-
 t/t9902-completion.sh  |  4 ++--
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 14dd5e7..6490553 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -531,6 +531,20 @@ __git_complete_strategy ()
return 1
 }
 
+if test -z $AUTHORIZED_CMD_LIST; then
+   __git_cmdlist ()
+   { 
+   echo $1;
+   }
+else
+   __git_cmdlist ()
+   { 
+   if [[  $AUTHORIZED_CMD_LIST  =~  $1  ]] ; then
+   echo $1
+   fi
+   }
+fi
+
 __git_list_all_commands ()
 {
local i IFS= $'\n'
@@ -538,7 +552,7 @@ __git_list_all_commands ()
do
case $i in
*--*) : helper pattern;;
-   *) echo $i;;
+   *) __git_cmdlist $i;;
esac
done
 }
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..5e7d81e 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -12,8 +12,8 @@ complete ()
# do nothing
return 0
 }
-
-. $GIT_BUILD_DIR/contrib/completion/git-completion.bash
+AUTHORIZED_CMD_LIST= checkout show add filter-branch ls-files send-email 
describe
+. $GIT_BUILD_DIR/contrib/completion/git-completion.bash 
 
 # We don't need this function to actually join words or do anything special.
 # Also, it's cleaner to avoid touching bash's internal completion variables.
-- 
1.8.1.1.271.g02f55e6

--
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] t9902: Instruct git-completion.bash about a test mode

[Jean-Noël AVILA]

Le jeudi 24 janvier 2013 22:46:13, Junio C Hamano a écrit :
 Jean-Noël AVILA jn.av...@free.fr writes:
 
  In test mode, git completion should propose commands only if they
  belong to the list of authorized commands.
 
  Signed-off-by: Jean-Noel Avila jn.av...@free.fr
  ---
 
  Better show some code than try to explain. Here is what I mean by
  filter the output git help -a. 
 
 Why do you have to make an extra shell function call for each and
 every possible Git subcommand to slow down everybody's work when not
 in testing mode?
 

My rational was to be sure to put the environment variable out of the 
way once the script has been sourced. I can make two alternative 
definitions of __git_list_all_commands () depending on the presence of 
$AUTHORIZED_CMD_LIST if you are worried about performance.

 Comparing it with Peff's suggestion, it is fairly clear which one we
 should pick, I think.
 
 
 
   contrib/completion/git-completion.bash | 16 +++-
   t/t9902-completion.sh  |  4 ++--
   2 files changed, 17 insertions(+), 3 deletions(-)
 
  diff --git a/contrib/completion/git-completion.bash 
  b/contrib/completion/git-completion.bash
  index 14dd5e7..6490553 100644
  --- a/contrib/completion/git-completion.bash
  +++ b/contrib/completion/git-completion.bash
  @@ -531,6 +531,20 @@ __git_complete_strategy ()
  return 1
   }
   
  +if test -z $AUTHORIZED_CMD_LIST; then
  +   __git_cmdlist ()
  +   { 
  +   echo $1;
  +   }
  +else
  +   __git_cmdlist ()
  +   { 
  +   if [[  $AUTHORIZED_CMD_LIST  =~  $1  ]] ; then
  +   echo $1
  +   fi
  +   }
  +fi
  +
   __git_list_all_commands ()
   {
  local i IFS= $'\n'
  @@ -538,7 +552,7 @@ __git_list_all_commands ()
  do
  case $i in
  *--*) : helper pattern;;
  -   *) echo $i;;
  +   *) __git_cmdlist $i;;
  esac
  done
   }
  diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
  index 3cd53f8..5e7d81e 100755
  --- a/t/t9902-completion.sh
  +++ b/t/t9902-completion.sh
  @@ -12,8 +12,8 @@ complete ()
  # do nothing
  return 0
   }
  -
  -. $GIT_BUILD_DIR/contrib/completion/git-completion.bash
  +AUTHORIZED_CMD_LIST= checkout show add filter-branch ls-files send-email 
  describe
  +. $GIT_BUILD_DIR/contrib/completion/git-completion.bash 
   
   # We don't need this function to actually join words or do anything 
  special.
   # Also, it's cleaner to avoid touching bash's internal completion 
  variables.
 --
 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
 
--
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] t9902: Instruct git-completion.bash about a test mode

[Jean-Noël AVILA]

Le jeudi 24 janvier 2013 23:29:33, Junio C Hamano a écrit :
 Jean-Noël AVILA jn.av...@free.fr writes:
 
  My rational was to be sure to put the environment variable out of the 
  way once the script has been sourced. I can make two alternative 
  definitions of __git_list_all_commands () depending on the presence of 
  $AUTHORIZED_CMD_LIST if you are worried about performance.
 
 Actually, it does not matter, as once __git_list_all_commands is
 run, its result is kept in a variable.
 
 So Peff's
 
   if test -z $FAKE_COMMAND_LIST; then
   __git_cmdlist() {
   git help -a | egrep '^  [a-zA-Z0-9]'
   }
   else
   __git_cmdlist() {
   printf '%s' $FAKE_COMMAND_LIST
   }
   fi
 
 would be just as simple if not simpler, does the same thing, and is
 sufficient, I think.
 
 The t9902 test is only interested in making sure that the completion
 works, and we do not want git help -a that omits a subcommand from
 its output that is not built in your particular environment to get
 in the way, which will not be an issue with this approach.
 


Ah. I totally missed the point. I though that the requested change was
to intersect the list needed for the test with the one provided by the 
standard completion.
--
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: [RFC] Instruct git-completion.bash that we are in test mode

[Jean-Noël Avila]

Le 22/01/2013 05:31, Junio C Hamano a écrit :

Jeff King p...@peff.net  writes:


 I really hate to suggest this, but should it be more like:

 if test -z $FAKE_COMMAND_LIST; then __git_cmdlist() { git help -a
 | egrep '^ [a-zA-Z0-9]' } else __git_cmdlist() { printf '%s'
 $FAKE_COMMAND_LIST } fi

 That gives us a nice predictable starting point for actually
 testing the completion code. The downside is that it doesn't let
 us test that we remain compatible with the output of help -a.

 Yeah, I think this is simpler and more to the point for the test in
 t9902. If we really want to test something that is the same as, or
 at least any closer than this approach (or my help --standard), to
 what the real users use, the test has to become inherently flaky, so
 I think we should go for the simplicity of this patch shows.

Instead of imposing the list of command, we could use the command
list argument to filter the ouput of git help -a. This would ensure that the
completions we want to test are still present in the installation while
still restricting them to the test case.


--
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

[RFC] Instruct git-completion.bash that we are in test mode

[Jean-Noël AVILA]

In test mode, git completion should only propose core commands.

Signed-off-by: Jean-Noel Avila jn.av...@free.fr
---

I reworked the patch so that the test argument is only evaluated
when sourcing the file and there is no environment clutter.

At least, it works for me.

 contrib/completion/git-completion.bash | 8 +++-
 t/t9902-completion.sh  | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 14dd5e7..ac9fa65 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -531,10 +531,16 @@ __git_complete_strategy ()
return 1
 }
 
+if [ x$1 != xTEST ]; then
+   __git_cmdlist () { git help -a|egrep '^  [a-zA-Z0-9]'; }
+else
+   __git_cmdlist () { git help -a| egrep -m 1 -B1000 PATH | egrep '^  
[a-zA-Z0-9]'; }
+fi
+
 __git_list_all_commands ()
 {
local i IFS= $'\n'
-   for i in $(git help -a|egrep '^  [a-zA-Z0-9]')
+   for i in $(__git_cmdlist)
do
case $i in
*--*) : helper pattern;;
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..51463b2 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -13,7 +13,7 @@ complete ()
return 0
 }
 
-. $GIT_BUILD_DIR/contrib/completion/git-completion.bash
+. $GIT_BUILD_DIR/contrib/completion/git-completion.bash TEST
 
 # We don't need this function to actually join words or do anything special.
 # Also, it's cleaner to avoid touching bash's internal completion variables.
-- 
1.8.1.1.271.g02f55e6

--
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: t9902 fails

[Jean-Noël AVILA]

Le samedi 19 janvier 2013 06:38:54, Torsten Bögershausen a écrit :
 On 18.01.13 23:23, Jean-Noël AVILA wrote:
  Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
  Junio C Hamano gits...@pobox.com writes:
  How about doing something like this and set that variable in the
  test instead?  If STD_ONLY is not set, you will get everything, but
  when STD_ONLY is set, we will stop reading from help -a when it
  starts listing additional stuff.
  
  I tried both of your propositions but none made test 10 of t9902 pass.
  
  Am I supposed to run make install before running the test?
 
 No. The test suite could (and should) be run before you make install.
 So a typical sequence could be:
 Run test suite, and if that passes, install the binaries on my system.
 This could look like this on the command line:
 make test  sudo make install
 
 Jean-Noël,
 would it be possible to run
 git status
 and share the result with us?
 
 And did you try Jonathans patch?
 
 /Torsten


Hi all,

My workdir is clean. 


jnavila@cayenne git (master)]$ make
GEN perl/PM.stamp
SUBDIR gitweb
SUBDIR ../
make[2]: « GIT-VERSION-FILE » est à jour.
GEN git-instaweb
SUBDIR git-gui
SUBDIR gitk-git
make[1]: Rien à faire pour « all ».
SUBDIR perl
SUBDIR git_remote_helpers
SUBDIR templates
[jnavila@cayenne git (master)]$ git branch -vv
  attr_pattern   3cb6a4c Add directory pattern matching to attributes
  fix_test_t9902 02f55e6 Merge git://bogomips.org/git-svn
  maint  611fa18 Add directory pattern matching to attributes
* master 02f55e6 [origin/master] Merge git://bogomips.org/git-svn
  next   82c5000 [origin/next: ahead 157, behind 550] Merge branch 
'jc/doc-diff-blobs' into next
  pu 25f269c [origin/pu: ahead 68, behind 137] Merge branch 
'mp/diff-algo-config' into pu
  todo   70e0e3e [origin/todo: behind 1] What's cooking (2013/01 #06)
[jnavila@cayenne git (master)]$ git status
# On branch master
# Untracked files:
#   (use git add file... to include in what will be committed)
#
#   gitk-git/gitk-wish
nothing added to commit but untracked files present (use git add to track)
[jnavila@cayenne git (master)]$ ls -l | grep git-check
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-check-attr
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-checkout
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-checkout-index
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-check-ref-format


If I move git-checkout-branches out of /usr/bin, the test passes. So somehow 
GIT_EXEC_PATH is not what is expected.


--
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 2/2] help --standard: list standard commands

[Jean-Noël AVILA]

Le samedi 19 janvier 2013 09:02:13, Junio C Hamano a écrit :
 If you run make on a branch that adds git check-ignore, checkout
 an older branch that did not know about the command without make clean,
 and the run t9902 test, the completion script fails to exclude the
 check-ignore command from candidates to complete check.
 
 This is because the completion script asks git help -a to show
 every executable that begins with git- in the GIT_EXEC_PATH, and
 because we run tests with GIT_EXEC_PATH set to the top of the
 working tree, that has the executable we just built, in order to
 test these before installing.  Leftover git check-ignore that we
 did not build for the current version gets in the way.
 
 One way to solve this is to restrict the completion to only the
 commands we know about.
 
 Note that this will make the completion useless in real life for
 some people, as they do want to get their custom commands on their
 $PATH to be included in the completion.
 
 Signed-off-by: Junio C Hamano gits...@pobox.com
 ---
 
  * This is not a real patch, for the reasons stated.
 
  builtin/help.c | 17 ++---
  command-list.txt   |  4 ++--
  contrib/completion/git-completion.bash | 14 +-
  generate-cmdlist.sh| 13 -
  help.c | 30 --
  help.h |  1 +
  6 files changed, 58 insertions(+), 21 deletions(-)
 
 diff --git a/builtin/help.c b/builtin/help.c
 index 6067a61..32e7d64 100644
 --- a/builtin/help.c
 +++ b/builtin/help.c
 @@ -35,11 +35,16 @@ enum help_format {
 
  static const char *html_path;
 
 -static int show_all = 0;
 +#define HELP_SHOW_ALL 1
 +#define HELP_SHOW_STANDARD 2
 +static int show_what;
  static unsigned int colopts;
  static enum help_format help_format = HELP_FORMAT_NONE;
  static struct option builtin_help_options[] = {
 - OPT_BOOLEAN('a', all, show_all, N_(print all available commands)),
 + OPT_SET_INT('a', all, show_what, N_(print all available commands),
 + HELP_SHOW_ALL),
 + OPT_SET_INT(0, standard, show_what, N_(print all available
 commands), + HELP_SHOW_STANDARD),
   OPT_SET_INT('m', man, help_format, N_(show man page),
 HELP_FORMAT_MAN), OPT_SET_INT('w', web, help_format, N_(show manual in
 web browser), HELP_FORMAT_WEB),
 @@ -424,12 +429,18 @@ int cmd_help(int argc, const char **argv, const char
 *prefix) builtin_help_usage, 0);
   parsed_help_format = help_format;
 
 - if (show_all) {
 + if (show_what == HELP_SHOW_ALL) {
   git_config(git_help_config, NULL);
   printf(_(usage: %s%s), _(git_usage_string), \n\n);
   list_commands(colopts, main_cmds, other_cmds);
   printf(%s\n, _(git_more_info_string));
   return 0;
 + } else if (show_what == HELP_SHOW_STANDARD) {
 + int i;
 + limit_to_standard(main_cmds);
 + for (i = 0; i  main_cmds.cnt; i++)
 + printf(%s\n, main_cmds.names[i]-name);
 + return 0;
   }
 
   if (!argv[0]) {
 diff --git a/command-list.txt b/command-list.txt
 index 7e8cfec..94ce8ec 100644
 --- a/command-list.txt
 +++ b/command-list.txt
 @@ -116,8 +116,8 @@ git-showmainporcelain
 common git-show-branch ancillaryinterrogators
  git-show-index  plumbinginterrogators
  git-show-refplumbinginterrogators
 -git-sh-i18n purehelpers
 -git-sh-setuppurehelpers
 +git-sh-i18n purehelpers nocomplete
 +git-sh-setuppurehelpers nocomplete
  git-stash   mainporcelain
  git-status  mainporcelain common
  git-stripspace  purehelpers
 diff --git a/contrib/completion/git-completion.bash
 b/contrib/completion/git-completion.bash index a4c48e1..46f22af 100644
 --- a/contrib/completion/git-completion.bash
 +++ b/contrib/completion/git-completion.bash
 @@ -531,23 +531,11 @@ __git_complete_strategy ()
   return 1
  }
 
 -__git_list_all_commands ()
 -{
 - local i IFS= $'\n'
 - for i in $(git help -a|egrep '^  [a-zA-Z0-9]')
 - do
 - case $i in
 - *--*) : helper pattern;;
 - *) echo $i;;
 - esac
 - done
 -}
 -
  __git_all_commands=
  __git_compute_all_commands ()
  {
   test -n $__git_all_commands ||
 - __git_all_commands=$(__git_list_all_commands)
 + __git_all_commands=$(git help --standard)
  }
 
  __git_list_porcelain_commands ()
 diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
 index 9a4c9b9..7800af3 100755
 --- a/generate-cmdlist.sh
 +++ b/generate-cmdlist.sh
 @@ -9,7 +9,7 @@ struct cmdname_help {
  static struct cmdname_help 

Re: Re* t9902 fails

[Jean-Noël AVILA]

Le samedi 19 janvier 2013 08:52:25, Junio C Hamano a écrit :
  (2) instead of being inclusive, collecting all executable in
  GIT_EXEC_PATH that happens to be named git-, add a mode to
  git help that lists those that we know to be standard
  commands that the users may want to complete from the command
  line.

Am I wrong when I say that git help -a already provides the difference 
between core git commands and other commands available through path?

If we use this, then we can instruct git-completion that we are in test mode 
and that it should not provide additional completions.

---
 contrib/completion/git-completion.bash | 13 +++--
 t/t9902-completion.sh  |  2 +-
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-
completion.bash
index 14dd5e7..dc0ea5b 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -23,6 +23,8 @@
 #3) Consider changing your PS1 to also show the current branch,
 #   see git-prompt.sh for details.
 
+__testing_git=$1
+
 case $COMP_WORDBREAKS in
 *:*) : great ;;
 *)   COMP_WORDBREAKS=$COMP_WORDBREAKS:
@@ -533,8 +535,15 @@ __git_complete_strategy ()
 
 __git_list_all_commands ()
 {
-   local i IFS= $'\n'
-   for i in $(git help -a|egrep '^  [a-zA-Z0-9]')
+   local i cmdlist IFS= $'\n'
+
+   if [ x$__testing_git != xTEST ]; then
+   cmdlist=$(git help -a|egrep '^  [a-zA-Z0-9]')
+   else
+   cmdlist=$(git help -a| egrep -m 1 -B1000 PATH | egrep '^  
[a-zA-Z0-9]')
+   fi
+
+   for i in $cmdlist
do
case $i in
*--*) : helper pattern;;
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..51463b2 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -13,7 +13,7 @@ complete ()
return 0
 }
 
-. $GIT_BUILD_DIR/contrib/completion/git-completion.bash
+. $GIT_BUILD_DIR/contrib/completion/git-completion.bash TEST
 
 # We don't need this function to actually join words or do anything special.
 # Also, it's cleaner to avoid touching bash's internal completion variables.
-- 
1.8.1.1.271.g02f55e6

--
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: t9902 fails

[Jean-Noël AVILA]

Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
 Junio C Hamano gits...@pobox.com writes:
  How about doing something like this and set that variable in the
  test instead?  If STD_ONLY is not set, you will get everything, but
  when STD_ONLY is set, we will stop reading from help -a when it
  starts listing additional stuff.

I tried both of your propositions but none made test 10 of t9902 pass.

Am I supposed to run make install before running the test?

--
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] attr: fix off-by-one directory component length calculation

[Jean-Noël AVILA]

Thank you for the explanation.

I did not monitor the system calls when writing that patch. 
Where is the perf framework?

As the mistake is located in the find_basename function, I would propose a 
fix directly into it so that the output fits what the other functions expect.

Something in the line of:

diff --git a/attr.c b/attr.c
index d6d7190..b6e72f3 100644
--- a/attr.c
+++ b/attr.c
@@ -572,7 +572,7 @@ static const char *find_basename(const char *path)
if (*cp == '/'  cp[1])
last_slash = cp;
}
-   return last_slash ? last_slash + 1 : path;
+   return last_slash ? last_slash : path;
 }
 
 static void prepare_attr_stack(const char *path)
@@ -770,6 +770,10 @@ static void collect_all_attrs(const char *path)
check_all_attr[i].value = ATTR__UNKNOWN;
 
basename = find_basename(path);
+   /* the slash is included in the basename
+  so that it can be matched by a directory pattern */
+   if (basename != path)
+   basename++;
pathlen = strlen(path);
rem = attr_nr;
for (stk = attr_stack; 0  rem  stk; stk = stk-prev)

--
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] attr: fix off-by-one directory component length calculation

[Jean-Noël AVILA]

Le mardi 15 janvier 2013 20:29:16, Junio C Hamano a écrit :
 Jean-Noël AVILA avila...@gmail.com writes:
  Thank you for the explanation.
  
  I did not monitor the system calls when writing that patch.
  Where is the perf framework?
  
  As the mistake is located in the find_basename function, I would
  propose a fix directly into it so that the output fits what the other
  functions expect.
 
 Isn't that a crazy semantics for the function, though?  I would
 expect find_basename(/a/path/to/file) to return file, not
 /file.
 

Yes, it is. I was wrong on the meaning of basename. 

Btw, the test 10 to t9902 is failing on my Debian testing. Is it a known 
issue?
--
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 v2] Add directory pattern matching to attributes

[Jean-Noël AVILA]

Le mercredi 19 décembre 2012 22:44:59, vous avez écrit :
 Jean-Noël AVILA avila...@gmail.com writes:
  This patch was not reviewed when I submitted it for the second time.
 
 Did you miss this?
 


Grml, I did. Sorry for the noise.

--
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

[PATCHv2] Add directory pattern matching to attributes

[Jean-Noël AVILA]

The manpage of gitattributes says: The rules how the pattern
matches paths are the same as in .gitignore files and the gitignore
pattern matching has a pattern ending with / for directory matching.

This rule is specifically relevant for the 'export-ignore' rule used
for git archive.

Signed-off-by: Jean-Noel Avila jn.av...@free.fr
---
 archive.c   |3 ++-
 attr.c  |   32 --
 t/t5002-archive-attr-pattern.sh |   57 +++
 3 files changed, 83 insertions(+), 9 deletions(-)
 create mode 100644 t/t5002-archive-attr-pattern.sh

diff --git a/archive.c b/archive.c
index 4666404..93e00bb 100644
--- a/archive.c
+++ b/archive.c
@@ -120,6 +120,8 @@ static int write_archive_entry(const unsigned char *sha1, 
const char *base,
strbuf_add(path, args-base, args-baselen);
strbuf_add(path, base, baselen);
strbuf_addstr(path, filename);
+   if (S_ISDIR(mode) || S_ISGITLINK(mode))
+   strbuf_addch(path, '/');
path_without_prefix = path.buf + args-baselen;
 
setup_archive_check(check);
@@ -130,7 +132,6 @@ static int write_archive_entry(const unsigned char *sha1, 
const char *base,
}
 
if (S_ISDIR(mode) || S_ISGITLINK(mode)) {
-   strbuf_addch(path, '/');
if (args-verbose)
fprintf(stderr, %.*s\n, (int)path.len, path.buf);
err = write_entry(args, sha1, path.buf, path.len, mode);
diff --git a/attr.c b/attr.c
index 097ae87..cdba88a 100644
--- a/attr.c
+++ b/attr.c
@@ -564,17 +564,31 @@ static void bootstrap_attr_stack(void)
attr_stack = elem;
 }
 
+static const char *find_basename(const char *path)
+{
+   char pathbuf[PATH_MAX];
+   int pathlen;
+   const char *cp;
+
+   pathlen =strlen(path);
+   if (path[pathlen-1] != '/') {
+   cp =strrchr(path, '/');
+   return cp ? cp + 1: path;
+   } else {
+   strncpy(pathbuf, path, pathlen);
+   pathbuf[pathlen-1] = '\0';
+   cp =strrchr(pathbuf, '/');
+   return cp ? path + (cp - pathbuf) + 1 : path;
+   }
+}
+
 static void prepare_attr_stack(const char *path)
 {
struct attr_stack *elem, *info;
int dirlen, len;
const char *cp;
 
-   cp = strrchr(path, '/');
-   if (!cp)
-   dirlen = 0;
-   else
-   dirlen = cp - path;
+   dirlen = find_basename(path) - path;
 
/*
 * At the bottom of the attribute stack is the built-in
@@ -668,6 +682,10 @@ static int path_matches(const char *pathname, int pathlen,
const char *pattern = pat-pattern;
int prefix = pat-nowildcardlen;
 
+   if ((pat-flags  EXC_FLAG_MUSTBEDIR) 
+   ((!pathlen) || (pathname[pathlen-1] != '/')))
+   return 0;
+
if (pat-flags  EXC_FLAG_NODIR) {
return match_basename(basename,
  pathlen - (basename - pathname),
@@ -758,9 +776,7 @@ static void collect_all_attrs(const char *path)
for (i = 0; i  attr_nr; i++)
check_all_attr[i].value = ATTR__UNKNOWN;
 
-   basename = strrchr(path, '/');
-   basename = basename ? basename + 1 : path;
-
+   basename = find_basename(path);
pathlen = strlen(path);
rem = attr_nr;
for (stk = attr_stack; 0  rem  stk; stk = stk-prev)
diff --git a/t/t5002-archive-attr-pattern.sh b/t/t5002-archive-attr-pattern.sh
new file mode 100644
index 000..0c847fb
--- /dev/null
+++ b/t/t5002-archive-attr-pattern.sh
@@ -0,0 +1,57 @@
+#!/bin/sh
+
+test_description='git archive attribute pattern tests'
+
+. ./test-lib.sh
+
+test_expect_exists() {
+   test_expect_success  $1 exists test -e $1
+}
+
+test_expect_missing() {
+   test_expect_success  $1 does not exist test ! -e $1
+}
+
+test_expect_success 'setup' '
+   echo ignored ignored 
+   echo ignored export-ignore .git/info/attributes 
+   git add ignored 
+
+   mkdir not-ignored-dir 
+   echo ignored-in-tree not-ignored-dir/ignored 
+   echo not-ignored-in-tree not-ignored-dir/ignored-only-if-dir 
+   git add not-ignored-dir 
+
+   mkdir ignored-only-if-dir 
+   echo ignored by ignored dir ignored-only-if-dir/ignored-by-ignored-dir 

+   echo ignored-only-if-dir/ export-ignore .git/info/attributes 
+   git add ignored-only-if-dir 
+
+
+   mkdir -p one-level-lower/two-levels-lower/ignored-only-if-dir 
+   echo ignored by ignored dir 
one-level-lower/two-levels-lower/ignored-only-if-dir/ignored-by-ignored-dir 
+   git add one-level-lower 
+
+   git commit -m. 
+
+   git clone --bare . bare 
+   cp .git/info/attributes bare/info/attributes
+'
+
+test_expect_success 'git archive' '
+   git archive HEAD archive.tar 
+   (mkdir archive  cd archive  $TAR xf -) archive.tar
+'
+
+test_expect_missingarchive/ignored

[PATCH] Add directory pattern matching to attributes

[Jean-Noël AVILA]

The manpage of gitattributes says: The rules how the pattern
matches paths are the same as in .gitignore files and the gitignore
pattern rules has a pattern ending with / for directory matching.

This rule is specifically relevant for the 'export-ignore' rule used
for git archive.

Signed-off-by: Jean-Noel Avila jn.av...@free.fr
---
 archive.c   |2 +-
 attr.c  |   47 -
 attr.h  |4 ++--
 builtin/check-attr.c|7 --
 builtin/pack-objects.c  |2 +-
 convert.c   |2 +-
 ll-merge.c  |4 ++--
 t/t5002-archive-attr-pattern.sh |   49 +++
 userdiff.c  |2 +-
 ws.c|2 +-
 10 files changed, 94 insertions(+), 27 deletions(-)
 create mode 100644 t/t5002-archive-attr-pattern.sh

diff --git a/archive.c b/archive.c
index 4666404..b8ff14f 100644
--- a/archive.c
+++ b/archive.c
@@ -123,7 +123,7 @@ static int write_archive_entry(const unsigned char *sha1, 
const char *base,
path_without_prefix = path.buf + args-baselen;
 
setup_archive_check(check);
-   if (!git_check_attr(path_without_prefix, ARRAY_SIZE(check), check)) {
+   if (!git_check_attr(path_without_prefix, mode, ARRAY_SIZE(check), 
check)) {
if (ATTR_TRUE(check[0].value))
return 0;
args-convert = ATTR_TRUE(check[1].value);
diff --git a/attr.c b/attr.c
index 887a9ae..da386f2 100644
--- a/attr.c
+++ b/attr.c
@@ -548,7 +548,7 @@ static void bootstrap_attr_stack(void)
attr_stack = elem;
 }
 
-static void prepare_attr_stack(const char *path)
+static void prepare_attr_stack(const char *path, unsigned mode)
 {
struct attr_stack *elem, *info;
int dirlen, len;
@@ -645,28 +645,43 @@ static void prepare_attr_stack(const char *path)
 }
 
 static int path_matches(const char *pathname, int pathlen,
-   const char *pattern,
+   const unsigned mode, char *pattern,
const char *base, int baselen)
 {
-   if (!strchr(pattern, '/')) {
+   size_t len;
+   char buf[PATH_MAX];
+   char * lpattern = buf;
+   len = strlen(pattern);
+   if (PATH_MAX = len)
+   return 0;
+   strncpy(buf,pattern,len);
+   buf[len] ='\0';
+   if (len  lpattern[len - 1] == '/') {
+   if (S_ISDIR(mode))
+   lpattern[len - 1] = '\0';
+   else
+   return 0;
+   }
+
+   if (!strchr(lpattern, '/')) {
/* match basename */
const char *basename = strrchr(pathname, '/');
basename = basename ? basename + 1 : pathname;
-   return (fnmatch_icase(pattern, basename, 0) == 0);
+   return (fnmatch_icase(lpattern, basename, 0) == 0);
}
/*
 * match with FNM_PATHNAME; the pattern has base implicitly
 * in front of it.
 */
-   if (*pattern == '/')
-   pattern++;
+   if (*lpattern == '/')
+   lpattern++;
if (pathlen  baselen ||
(baselen  pathname[baselen] != '/') ||
strncmp(pathname, base, baselen))
return 0;
if (baselen != 0)
baselen++;
-   return fnmatch_icase(pattern, pathname + baselen, FNM_PATHNAME) == 0;
+   return fnmatch_icase(lpattern, pathname + baselen, FNM_PATHNAME) == 0;
 }
 
 static int macroexpand_one(int attr_nr, int rem);
@@ -693,7 +708,7 @@ static int fill_one(const char *what, struct match_attr *a, 
int rem)
return rem;
 }
 
-static int fill(const char *path, int pathlen, struct attr_stack *stk, int rem)
+static int fill(const char *path, int pathlen, unsigned mode, struct 
attr_stack *stk, int rem)
 {
int i;
const char *base = stk-origin ? stk-origin : ;
@@ -702,7 +717,7 @@ static int fill(const char *path, int pathlen, struct 
attr_stack *stk, int rem)
struct match_attr *a = stk-attrs[i];
if (a-is_macro)
continue;
-   if (path_matches(path, pathlen,
+   if (path_matches(path, pathlen, mode,
 a-u.pattern, base, strlen(base)))
rem = fill_one(fill, a, rem);
}
@@ -737,26 +752,26 @@ static int macroexpand_one(int attr_nr, int rem)
  * Collect all attributes for path into the array pointed to by
  * check_all_attr.
  */
-static void collect_all_attrs(const char *path)
+static void collect_all_attrs(const char *path, unsigned mode)
 {
struct attr_stack *stk;
int i, pathlen, rem;
 
-   prepare_attr_stack(path);
+   prepare_attr_stack(path, mode);
for (i = 0; i  attr_nr; i++)
check_all_attr[i].value = ATTR__UNKNOWN;
 
pathlen 

[PATCH] Add directory pattern matching to attributes

[Jean-Noël AVILA]

The manpage of gitattributes says: The rules how the pattern
matches paths are the same as in .gitignore files and the gitignore
pattern rules has a pattern ending with / for directory matching.

This rule is specifically relevant for the 'export-ignore' rule used
for git archive.

Signed-off-by: Jean-Noel Avila jn.av...@free.fr
---
 archive.c   |2 +-
 attr.c  |   47 -
 attr.h  |4 ++--
 builtin/check-attr.c|7 --
 builtin/pack-objects.c  |2 +-
 convert.c   |2 +-
 ll-merge.c  |4 ++--
 t/t5002-archive-attr-pattern.sh |   49 +++
 userdiff.c  |2 +-
 ws.c|2 +-
 10 files changed, 94 insertions(+), 27 deletions(-)
 create mode 100644 t/t5002-archive-attr-pattern.sh

diff --git a/archive.c b/archive.c
index 4666404..b8ff14f 100644
--- a/archive.c
+++ b/archive.c
@@ -123,7 +123,7 @@ static int write_archive_entry(const unsigned char *sha1, 
const char *base,
path_without_prefix = path.buf + args-baselen;
 
setup_archive_check(check);
-   if (!git_check_attr(path_without_prefix, ARRAY_SIZE(check), check)) {
+   if (!git_check_attr(path_without_prefix, mode, ARRAY_SIZE(check), 
check)) {
if (ATTR_TRUE(check[0].value))
return 0;
args-convert = ATTR_TRUE(check[1].value);
diff --git a/attr.c b/attr.c
index 887a9ae..da386f2 100644
--- a/attr.c
+++ b/attr.c
@@ -548,7 +548,7 @@ static void bootstrap_attr_stack(void)
attr_stack = elem;
 }
 
-static void prepare_attr_stack(const char *path)
+static void prepare_attr_stack(const char *path, unsigned mode)
 {
struct attr_stack *elem, *info;
int dirlen, len;
@@ -645,28 +645,43 @@ static void prepare_attr_stack(const char *path)
 }
 
 static int path_matches(const char *pathname, int pathlen,
-   const char *pattern,
+   const unsigned mode, char *pattern,
const char *base, int baselen)
 {
-   if (!strchr(pattern, '/')) {
+   size_t len;
+   char buf[PATH_MAX];
+   char * lpattern = buf;
+   len = strlen(pattern);
+   if (PATH_MAX = len)
+   return 0;
+   strncpy(buf,pattern,len);
+   buf[len] ='\0';
+   if (len  lpattern[len - 1] == '/') {
+   if (S_ISDIR(mode))
+   lpattern[len - 1] = '\0';
+   else
+   return 0;
+   }
+
+   if (!strchr(lpattern, '/')) {
/* match basename */
const char *basename = strrchr(pathname, '/');
basename = basename ? basename + 1 : pathname;
-   return (fnmatch_icase(pattern, basename, 0) == 0);
+   return (fnmatch_icase(lpattern, basename, 0) == 0);
}
/*
 * match with FNM_PATHNAME; the pattern has base implicitly
 * in front of it.
 */
-   if (*pattern == '/')
-   pattern++;
+   if (*lpattern == '/')
+   lpattern++;
if (pathlen  baselen ||
(baselen  pathname[baselen] != '/') ||
strncmp(pathname, base, baselen))
return 0;
if (baselen != 0)
baselen++;
-   return fnmatch_icase(pattern, pathname + baselen, FNM_PATHNAME) == 0;
+   return fnmatch_icase(lpattern, pathname + baselen, FNM_PATHNAME) == 0;
 }
 
 static int macroexpand_one(int attr_nr, int rem);
@@ -693,7 +708,7 @@ static int fill_one(const char *what, struct match_attr *a, 
int rem)
return rem;
 }
 
-static int fill(const char *path, int pathlen, struct attr_stack *stk, int rem)
+static int fill(const char *path, int pathlen, unsigned mode, struct 
attr_stack *stk, int rem)
 {
int i;
const char *base = stk-origin ? stk-origin : ;
@@ -702,7 +717,7 @@ static int fill(const char *path, int pathlen, struct 
attr_stack *stk, int rem)
struct match_attr *a = stk-attrs[i];
if (a-is_macro)
continue;
-   if (path_matches(path, pathlen,
+   if (path_matches(path, pathlen, mode,
 a-u.pattern, base, strlen(base)))
rem = fill_one(fill, a, rem);
}
@@ -737,26 +752,26 @@ static int macroexpand_one(int attr_nr, int rem)
  * Collect all attributes for path into the array pointed to by
  * check_all_attr.
  */
-static void collect_all_attrs(const char *path)
+static void collect_all_attrs(const char *path, unsigned mode)
 {
struct attr_stack *stk;
int i, pathlen, rem;
 
-   prepare_attr_stack(path);
+   prepare_attr_stack(path, mode);
for (i = 0; i  attr_nr; i++)
check_all_attr[i].value = ATTR__UNKNOWN;
 
pathlen 

Bug report : gitattribute export-ignore behavior does not match documentation

[Jean-Noël AVILA]

Tested on latest maint and master.

The 'export-ignore' gitattribute is documented as behaving on a pattern, just 
like in .gitignore.

In repo where I have a tree like this:

.gitattributes
figures/
fr/figures/

I want to remove from archive all the figures directories. So I added 

figures/ export-ignore 

to the top level .gitattributes file.

but then:

$  git check-attr -a fr/figures
$  git check-attr -a figures
$

If I change the line in .gitattributes to :

figures export-ignore

I get the correct result, but I am not sure to exclude only directories.

Am I wrong somewhere?

Thank you.

Jean-Noël AVILA
--
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