[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: git-merge-changelog limitation? [was: [PATCH] parse-datetime: do some more renaming]
Date: Tue, 05 Oct 2010 15:12:34 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100921 Fedora/3.1.4-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.4

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]