[pology] Pology posummit not propagating header changes to branch PO files

[Chusslove Illich]

Exactly the behavior you described is in fact not a bug, not even an
unexpected consequence, but explicitly programmed-in :) I.e. by just
removing a few lines in code the behaviour would revert to how you
expected it to be.

The idea was as follows. If there was a branch PO with proper
PO-Revision-Date and and Last-Translator headers, the values of those
fields would hold true for the content of all messages; so if none of
the messages change on scatter, neither should the two particular
headers.

In practice, imagine you were changing a piece of terminology in a few
summit PO files, and saved the files, so that summit PO headers got
updated with the current date and your name. But then you decided the new
term doesn't really function well, so you went back and changed to the
old term (instead of just version-control reverting the files). Now the
header fields would reflect the changes which actually never happened,
so no reason to update them in branch POs. Or maybe there was an
automatic script run over the PO summit files, which for some reason
update the two headers, while the content of messages remained the same.
I can't remember what exactly pushed me to implement special handling of
these headers, but it must have been something along these lines.

(On a side note, there are another two headers which are never copied to
branch POs, Report-Msgid-Bugs-To and POT-Creation-Date. Because these
are supposed to be updated only on merge with templates, so they get
updated on merge of branch POs with branch POTs only.)

Now, if the branch PO for some reason didn't have proper
PO-Revision-Date and and Last-Translator, for example if the tool with
which last time the summit PO was edited didn't update them, then of
course it might be worth overwriting them from the summit PO (after it
has been edited with a tool that did update the fields properly).
However this is the "bad case", so the "good case" described above takes
precedence in principle.

I would however not be against implementing an option (for
messages.extras.summit) to unconditionally update branch
PO-Revision-Date and and Last-Translator, and it should be easy to do.
Then if the "bad case" is more likely to happen than the "good case", it
would be worth setting this option.

--
Chusslove Illich (Часлав Илић)