[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
git-merge-changelog limitation? [was: [PATCH] parse-datetime: do some mo
git-merge-changelog limitation? [was: [PATCH] parse-datetime: do some more renaming]
Tue, 05 Oct 2010 15:12:34 -0600
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) 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:
@@ -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
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