git-merge-changelog limitation? [was: [PATCH] parse-datetime: do some more renaming]

[Eric Blake]

On 10/05/2010 02:52 PM, Paul Eggert wrote:
> +++ b/ChangeLog
> @@ -1,5 +1,12 @@
>   2010-10-05  Paul Eggert<address@hidden>
>
> +       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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org