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

On Thu, Sep 2, 2010 at 20:37, Jonathan Nieder [off-list ref] wrote:

Ævar Arnfjörð Bjarmason wrote:

quoted

It's on top of pu,

[...]

quoted

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.