Matthieu Moy <> writes:

> Junio C Hamano <> writes:
>>> +{
>>> +   if (files_list->nr) {
>>> +           struct strbuf err_msg = STRBUF_INIT;
>>> +           int i;
>>> +           strbuf_addstr(&err_msg, main_msg);
>>> +           for (i = 0; i < files_list->nr; i++)
>>> +                   strbuf_addf(&err_msg,
>>> +                               "\n    %s",
>> Is there an implication of having always 4 spaces here to l10n/i18n
>> here?  I am wondering if it should be _("\n    %s").
> I'd say this is just formatting and should be the same in every
> languages, but I'm far from an expert in the domain.

After looking at the patch again I do not think 4-SP matters.  I was
primarily worried if this was to align with some column of the first
line of output, e.g.

        error: lorem ipsum dolor sit amet, consectetur adipisicing
               elit, sed do eiusmod tempor incididunt ut labore et
               dolore magna aliqua.

but that is not what this 4-SP indent is about, so it is OK.

>>         test_expect_success 'rm files with different staged content' '
>>                 cat >expect <<\-EOF &&
> (that should be -\EOF, not \-EOF I think)

Sorry, my bad.  You are of course right.

>>  (2) by using a dash '-' before the end-of-here-text marker, you can
>>      align the body of here text with a leading tab (HT).
> This works because the list of files is aligned with spaces, but is
> seems a bit fragile to me to use this -EOF on a text which uses
> indentation. Anyway, I'm fine with both.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to