git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Osamu OKANO <okano.osamu@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 6/7] update git-stage.po
Date: Sun, 15 May 2011 15:25:48 +0200	[thread overview]
Message-ID: <BANLkTin3hVusWc-oubW5T-L=mCatubHiKA@mail.gmail.com> (raw)
In-Reply-To: <20110515130856.GB3178@elie>

On Sun, May 15, 2011 at 15:08, Jonathan Nieder <jrnieder@gmail.com> 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 :)

  reply	other threads:[~2011-05-15 13:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-13 13:14 [PATCH 0/7] Document translation with po4a Osamu OKANO
2011-05-13 13:14 ` [PATCH 1/7] Add new target pot in Makefile Osamu OKANO
2011-05-13 13:14 ` [PATCH 2/7] add make(shell) scripts Osamu OKANO
2011-05-13 13:14 ` [PATCH 3/7] cp git-stage.pot ja/git-stage.po Osamu OKANO
2011-05-13 13:14 ` [PATCH 4/7] translate ja/git-stage.po Osamu OKANO
2011-05-13 13:14 ` [PATCH 5/7] your file Osamu OKANO
2011-05-13 16:52   ` Junio C Hamano
2011-05-13 16:58   ` Drew Northup
2011-05-13 13:14 ` [PATCH 6/7] update git-stage.po Osamu OKANO
2011-05-13 16:53   ` Junio C Hamano
2011-05-14 13:36     ` Osamu OKANO
2011-05-14 19:21       ` Jonathan Nieder
2011-05-15  3:21         ` Junio C Hamano
2011-05-15  3:44           ` Jonathan Nieder
2011-05-15 12:51         ` Ævar Arnfjörð Bjarmason
2011-05-15 12:56           ` Jonathan Nieder
2011-05-15 13:08           ` Jonathan Nieder
2011-05-15 13:25             ` Ævar Arnfjörð Bjarmason [this message]
2011-05-15 13:51               ` Jonathan Nieder
2011-05-13 13:14 ` [PATCH 7/7] translate and remove fazzy Osamu OKANO
2011-05-13 16:48 ` [PATCH 0/7] Document translation with po4a Junio C Hamano
2011-05-14  9:14   ` Ævar Arnfjörð Bjarmason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTin3hVusWc-oubW5T-L=mCatubHiKA@mail.gmail.com' \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=okano.osamu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).