[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: git-merge-changelog limitation?
From: |
Bruno Haible |
Subject: |
Re: git-merge-changelog limitation? |
Date: |
Wed, 6 Oct 2010 00:05:40 +0200 |
User-agent: |
KMail/1.9.9 |
Hi Eric,
> 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
Yes, I agree, it looks like this.
> at which point I did 'git pull --rebase'.
I also use 'git pull --rebase' often, and git-merge-changelog brings the
ChangeLog entries into the right order.
> Apparently, git 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.
Well, I would consider it a bug in git if it didn't invoke the declared
merge driver. That is the point of a custom 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.
Yes, please. This will be useful to revisit once we have unit tests for
the normal operation of git-merge-changelog.
Bruno