Re: [ANNOUNCE] Git v2.8.0-rc2

[Michael J Gruber <git@drmicha.warpmail.net>]

Junio C Hamano venit, vidit, dixit 16.03.2016 17:30:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> echo '*.po diff=po' >>.gitattributes
>> echo '*.pot diff=po' >>.gitattributes
>> git config diff.po.textconv "msgcat --indent --no-location"
>>
>> With or without the indent, that gives a pretty clean diff. [It's
>> unfortunate that one half of that config is in-tree, one-half is not.]
> 
> That's a good tip. [By the way, it is not unfortunate that these are
> separated to two places, but quite the opposite.  Attributes define
> "what kind of things" they are, and configuration defines "how" each
> kind of things are handled.  "msgcat" may have to be invoked
> differently from yours on other people's systems, and one level of
> indirection is a reasonable way to allow customizing "how" part
> without forcing people to rewrite all of THIS in "for *.po do THIS,
> for *.pot do THIS too".  You should be thankful for this separation.]

I know why we have that. It's just unfortunate that we can't even
provide a default textconfig config easily - I know very well we can't
have that securely.

"Unfortunate" is meant in this context in the sense: I want to make it
easy and convenient for non-l10n-people to watch out for l10-affecting
changes.

>> So, really, the "actual coders" know best whether their changes should
>> affect l10n or not, so they should be made more aware of it. Forcing
>> "make pot" (and maybe more) on everyone sounds a bit harsh, but what
>> else can we do?
> 
> I am not sure what problem you are trying to solve.  Do you want to
> make sure mismarking such as N_(("foo")) is caught by the person who
> changes "foo" into N_(("foo"))?

Yes. That and similar ones.

> "make pot" alone would obviously not help, and you would definitely
> need "maybe more" but I'd imagine that would involve checking the
> diff in the code part i.e. "we have a new N_(...)" against the
> differences in git.pot files you would obtain by running "make pot"
> before the code change and after the code change, i.e. "there is no
> new mention of "foo"".
> 
> I do not think you are suggesting to commit the result of "make pot"
> along with code changes, but if you are, please don't ;-)

As I said: I assume there's a good reason we don't do that, and that's
why I'm not suggesting it.

On the other hand, it means that the in-tree git.pot does not correlate
with the in-tree source code at all, which feels really weird[*]. And it
makes it difficult to check the impact of your code changes: You can't
simply run "make pot" and check the diff - because the in-tree git.pot
does not reflect the state before your changes at all.

[*] It just feels wrong to me that a "make pot" in a clean checkout
leads to dirty index.

So, in short, I do believe there is a good reason for the "out of sync"
git.pot. That doesn't make the negative side effect that I describe any
less true, and I'm looking for ways to ammeliorate that. Something as
easy as "make check" or "make test-lint".

Michael