Matthieu Moy <[email protected]> writes:
> Junio C Hamano <[email protected]> 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.
True.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
