The solution to this problem (if it is really a problem) is to keep around a side file with some errata. I have such a side file that I use with my script which compares two branches via git log. There's always commits where the wrong message got applied, or the jira number was missing, or etc. You can just have your script ignore those commits. Real-world data is always a little dirty.
Anyway, as Allen mentioned earlier, the git log is more likely to be correct than CHANGES.txt, since git never forgets to handle merges and cherry-picks, and humans often do. I think it's pretty rare to remember to do one but forget the other. It is true that CHANGES.txt can be mutated, whereas commit hashes cannot. But if the CHANGES.txt change update was a separate commit, most people doing backports and cherry-picks will miss it, so... I wouldn't count on that really helping things much. I certainly have no objection to generating CHANGES.txt and release notes off JIRA, which avoids some of these problems (jiras can be edited, after all). But JIRA has its own set of problems... it's not always available and it's centralized. If the JIRA REST APIs change, or the data center loses its backups, or you don't have a network connection, you can't examine JIRA. But you can always examine git log. Colin On Tue, Apr 7, 2015 at 3:51 PM, Allen Wittenauer <a...@altiscale.com> wrote: > > For those wondering, YARN-2429 is the wrong JIRA for that commit. Simple > typo, but deadly if one is using to use the git log to determine what’s > actually committed... >
