On 10/05/2010 02:52 PM, Paul Eggert wrote:
+++ b/ChangeLog @@ -1,5 +1,12 @@ 2010-10-05 Paul Eggert<egg...@cs.ucla.edu>+ parse-datetime: do some more renaming + * doc/parse-datetime.texi (Authors of parse_datetime): Call it + parse_datetime, not get_date. Mention the renaming. + * lib/parse-datetime.y: Call it parse_datetime, not getdate, + in comments. + * m4/bison.m4: Likewise. + more ports to Solaris tr, which needs [] around ranges
Hmm, ChangeLog now has some out-of-order entries. This is probably due to me working on the rename before Paul's patch for additional tr fixes, with two ChangeLog paragraphs grouped under one date; at which point I did 'git pull --rebase'. Apparently, get decided that since my change didn't impact line 1, it didn't have any reason to call git-merge-changelog; therefore, my most recent paragraph on parse-datetime renaming was not floated to the top, even though it was pushed upstream after Paul's tr fixes.
If my memory serves, this may be a 'feature' of newer git; older git would always run git-merge-changelog if one revision inserts at the file head while another inserted a paragraph at line 3. Or it may be an unintentional regression in git.
At any rate, I'm wondering if this means that we need to add a custom diff driver for ChangeLogs, in addition to the merge driver; so that we have final say on whether two ChangeLog edits require the use of the merge driver.
Let me know if you need me to spend time writing up an exact formula to reproduce the steps that led to my ChangeLog message not being rebased the way I think it should be.
-- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
