On Thu, Sep 2, 2010 at 20:37, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Æ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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html