Re: [PATCH 6/7] update git-stage.po

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, May 15, 2011 at 15:08, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Hi again,
>
> Ãvar ArnfjÃrà Bjarmason wrote:
>
>> We went over this for the main gettext series. Not commiting the line
>> numbers is unworkable, because it means that users who check out
>> git.git can't run msgmerge, because it completely fails without line
>> numbers.
>
> Please feel free to ignore my other reply. ÂYou were saying something
> helpful there, not just calling me out, and I completely misunderstood.

No problem. Sorry about the terseness. I don't have a lot of time for
mailing list trawling these days.

> I assume you were referring to this discussion:
>
> Âhttp://thread.gmane.org/gmane.comp.version-control.git/147973/focus=148044
>
> I'm confused about the msgmerge comment above. ÂI'll have to try it.
> But anyway, of course I agree with the more important point that not
> providing line numbers would make life harder for humans.
>
>> Having a merge strategy to deal with them would be nice, but that can
>> be done by using the existing gitattributes config + msgmerge(1) to do
>> the work.
>
> I'm still curious about this part, of course.

Maybe I'm just adding confusion here. I mean that as far as I can tell
we need to have the line numbers in the *.po files, I've been unable
to not make merges go horribly wrong without them.

Whenever I did a merge from git.pot to LANG.po where LANG.po didn't
have line numbers I ended up with issues like msgmerge confusing
strings between program A and program B, which doesn't happen if the
PO file has file:line comments.

But having them will result in merge conflicts using Git's default
merge strategy, which can be mitigated by using msgmerge(1) to resolve
the conflicts, since it knows to ignore the line numbers and to look
at the actual content.

We should be able to have a merge driver defined for git.git to do
that using the "Defining a custom merge driver" facility defined in
gitattributes(5), but I haven't actually tried to make one. But it
looks easy enough, I'll look at doing that when this becomes a problem
I have to deal with, and I'm hoping someone beats me to it :)
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]