po: Mark translations with mismatched printf format directives as fuzzy.

[Michael Stefaniuc]

On 09/26/2011 06:32 PM, Dan Kegel wrote:
> On Mon, Sep 26, 2011 at 2:59 AM, Jerome Leclanche <adys.wh at gmail.com> wrote:
>> On Mon, Sep 26, 2011 at 8:46 AM, Francois Gouget <fgouget at free.fr> wrote:
>>> On Sun, 25 Sep 2011, Dan Kegel wrote:
>>>> Patch fails to apply here?
>>>>
>>>> error: patch failed: po/ko.po:11305
>>>> error: po/ko.po: patch does not apply
>>>
>>> That's strange. The patch attached to the email I received on
>>> wine-patches applies fine on a pristine tree here.
>>
>> Sounds like encoding/charset issues. Dan, is buildbot's the same as
>> the file and/or patch?
> 
> Looks like patch and git apply disagree here:
> 
> 
> $ wget http://source.winehq.org/patches/data/79310
> $ git reset --hard origin
> $ patch -p1 < 79310
> patching file po/es.po
> patching file po/hu.po
> patching file po/ko.po
> Hunk #3 succeeded at 11307 with fuzz 2.
> patching file po/zh_CN.po
> $ git reset --hard origin
> HEAD is now at e5ba601 Release 1.3.29.
> $ git apply 79310
> error: patch failed: po/ko.po:11305
> error: po/ko.po: patch does not apply
> 
> I guess patch is more willing to fuzz than git apply is;
> man git-apply says
>        -C<n>
>            Ensure at least <n> lines of surrounding context match
> before and after each change.
>            When fewer lines of surrounding context exist they all must
> match. By default no context
>            is ever ignored.
> 
> I could use git apply -C 1 to match patch's behavior;
> what do people think?
Don't. There is a very good reason why git apply moved to that default
behavior. During my automatic patch generation and testing in the
pre-git times I got bitten quite a few times by patch doing the wrong
thing with fuzzying to the point of running patch -F 0. Also when
Alexandre does "git am" the patch it will fail too.

bye
	michael