git merge and GNU gettext po files - how to avoid conflicts?

David Bruce· Jul 10, 2010, 01:40 UTC · lore

Hello,

First of all, is this list suitable for git usage questions as opposed to git development? If not, what list is more appropriate?

Assuming this is an appropriate list, here is the issue:

The .po files used by gettext are largely human-generated, so they
need to be under scm control.  However, they are also programatically
altered when certain make targets are run.  When this happens, a line
in the .po file gets updated with timestamp info (not talking about a
filesystem timestamp here, but a change in the text file).  So, if two
branches have been worked on for a while and the updated .po files
have been committed in each branch, they will generate conflicts when
a merge is attempted.  Since our programs have lots of translations,
it is a pain to resolve all the conflicts by hand. What is a good way
to avoid this in git? My thought would be:
1. generate a diff between the .po files in the po/ directories of the
two branches, e.g.
(assuming we are trying to merge a branch named "feature" back with master):
git diff master feature po/*.po

and look to see if any differences are these innocuous, autogenerated differences. Perhaps some other type of diff would be more useful, such as diffs from a common ancestor?

2. If the diff shows that one of the branches has no changes in
po/*.po that need to be kept, is there a way to tell git to "merge
feature with master, but for po/*.po differences just use the file
from feature instead of generating conflicts".  Or, should I just
manually copy all the *.po files from one branch into the other branch
and commit them prior to attempting the merge?

It seems someone must have encountered and solved this problem before, but I haven't have much luck with Google, so I'd greatly appreciate hearing from someone with expertise.

Thanks for any help,

David Bruce

Jakub Narebski· Jul 10, 2010, 08:51 UTC · re: David Bruce · lore

Re: git merge and GNU gettext po files - how to avoid conflicts?

David Bruce <davidstuartbruce@gmail.com> writes:

> First of all, is this list suitable for git usage questions as opposed
> to git development?  If not, what list is more appropriate?

Yes, it is appropriate list.

Show 27 quoted lines

> Assuming this is an appropriate list, here is the issue:
> 
> The .po files used by gettext are largely human-generated, so they
> need to be under scm control.  However, they are also programatically
> altered when certain make targets are run.  When this happens, a line
> in the .po file gets updated with timestamp info (not talking about a
> filesystem timestamp here, but a change in the text file).  So, if two
> branches have been worked on for a while and the updated .po files
> have been committed in each branch, they will generate conflicts when
> a merge is attempted.  Since our programs have lots of translations,
> it is a pain to resolve all the conflicts by hand. What is a good way
> to avoid this in git? My thought would be:
> 1. generate a diff between the .po files in the po/ directories of the
> two branches, e.g.
> (assuming we are trying to merge a branch named "feature" back with master):
> git diff master feature po/*.po
> 
> and look to see if any differences are these innocuous, autogenerated
> differences.  Perhaps some other type of diff would be more useful,
> such as diffs from a common ancestor?
> 
> 2. If the diff shows that one of the branches has no changes in
> po/*.po that need to be kept, is there a way to tell git to "merge
> feature with master, but for po/*.po differences just use the file
> from feature instead of generating conflicts".  Or, should I just
> manually copy all the *.po files from one branch into the other branch
> and commit them prior to attempting the merge?

3. Create a merge driver intended specially for merging *.po files,
   just like there exists (in the wild) the strategy to merge ChangeLog
   files.  Then use gitattributes mechanism to associate this merge
   strategy with *.po files via `merge' attribute.

   But it might be not easy...

-- 
Jakub Narebski
Poland
ShadeHawk on #git