Re: [PATCH 10/25] gettextize: git-merge basic messages

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Sep 3, 2010, 13:01 UTC
Message-ID: <AANLkTi=5MrU-JyeQ3UVNbVwzn-8FbstUXafgcQaLWXDB@mail.gmail.com>
In-Reply-To: <20100902203711.GE2531@burratino>

On Thu, Sep 2, 2010 at 20:37, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 25 quoted lines

> Ævar Arnfjörð Bjarmason wrote:
>
>> It's on top of pu,
> [...]
>> But I was hoping that this would
>> make it into pu and after next gets released Any Day Now most of those
>> other tips in pu would be folded into next along with gettext, or at
>> least the merge conflicts wouldn't be too painful.
>
> Hmm.  That really constrains people trying to merge this series.
>
> As SubmittingPatches explains:
>
>  - In the exceptional case that a new feature depends on several topics
>   not in 'master', start working on 'next' or 'pu' privately and send
>   out patches for discussion. Before the final merge, you may have to
>   wait until some of the dependent topics graduate to 'master', and
>   rebase your work.
>
> so this is fine for discussion, but for merging, having to pull in
> _all_ topics from pu (or all topics from next for that matter) for
> the patches to apply really is a problem.
>
> Both next and pu get rewound from time to time.  They are not meant
> to be a stable basis for patches.

Junio: I've started work to rebase this whole thing on master, when
I'm done the result should be able to replace the existing ab/i18n
series you have, i.e. it won't have the Conflicts your "Merge branch
'ab/i18n'" commits have.

Also, I'm going to add a special POISON mode to Git so that we can check if changing these messages breaks anything in the test suite, basically:

    make GETTEXT_POISON=YesPlease

Which enables this in gettext.h:

    #ifdef GETTEXT_POISON
    #define _(s) "GETTEXT POISON"
    #else
    #define _(s) gettext(s)
    #endif

Which in my preliminary tests makes a bunch of tests fail, most of it is stuff like this in t0001-init.sh:

    #               grep "Initialized empty" again/out1 &&
    #               grep "Reinitialized existing" again/out2 &&
    #               >again/empty &&
    #               test_cmp again/empty again/err1 &&
    #               test_cmp again/empty again/err2

I.e. just something using the porcelain messages that are OK to translate. I'm going to add a new NO_GETTEXT_POISON test prereq to all of these, anything that remains would then indicate plumbing messages that shouldn't be translated.

Unfortunately we *don't* have complete test coverage so these sort of tests may miss something. But it should make this series a lot more robust.