[Top][All Lists]

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

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]

From: Eric Blake
Subject: Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Date: Tue, 08 Jun 2010 04:29:31 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100430 Fedora/3.0.4-3.fc13 Lightning/1.0b2pre Mnenhy/0.8.2 Thunderbird/3.0.4

[adding Bruno, as author of git-merge-changelog]

On 06/08/2010 04:14 AM, Peter Rosin wrote:
> I have git-merge-changelog. But my changes on the branch are in ChangeLog,
> and the question was where they should be after the merge, in ChangeLog
> or in ChangeLog.2009. I was not asking how the merge should be performed
> with as little hassle as possible.

Interesting question; I do think that it makes more sense to merge
entries into ChangeLog.2009 rotated file if the commit was made to the
published branch prior to 2010, and you aren't rebasing that branch.

>>> How should I resolve those conflicts? By adding the
>>> entries to ChangeLog.2009 or to ChangeLog? I think the "rule" is to
>>> commit with the date preserved even if that causes the ChangeLog to
>>> be unordered, but I don't know how that "rule" applies in the face
>>> of a ChangeLog rotation (or two)...
>> This is where the GNU Coding Standards are somewhat silent - they were
>> written in a day of CVS, when commits were made to a central repository
>> in strict order, so the date was always the date of the original commit.
>>  But nowadays, I'm personally fine seeing dates out of order, with the
>> understanding that the dates track the first commit on _someone's_
>> checkout, but list the order of commits into the upstream canonical
>> tree.  However, I also tend to personally re-date my Changelog entries
>> to the day that I'm pushing them upstream, but this can entail quite a
>> bit of work for a lengthy patch series.  And I do that by using 'git
>> rebase -i', so although the committer and ChangeLog date are the day I
>> push upstream, the author date is still my original date of writing the
>> patch.  And since 'git log' prefers author date over committer date,
>> that means that I often see out-of-order dates in the git log.  So I can
>> go either way.
> You don't seem to grok that the pr-msvc-support branch is upstream.

Rather, pr-msvc-support is a published branch, but I still don't
consider it on quite the same par as the 'master' branch.  That is, you
are correct that it would no longer be polite to rebase pr-msvc-support
without good reason (and just fixing changelog locations doesn't qualify
as a good reason on my part).  But doing a 'git merge', where the new
commit has a head of both 'master' and 'pr-msvc-support', and having
that merge commit sort out all the ChangeLog contents, is reasonable.
It gets tricky here, because gnulib doesn't really use git merge
(automake does, but many other GNU projects are still using git in a
linear manner).  There may well be some shortcomings in
git-merge-changelog for how it is used, in the face of rotated
changelogs or in the face of 'git merge' rather than 'git rebase', that
may need tweaking.

> Sorry for not being explicit about that, but please answer again when
> taking that fact into account. I don't want to rebase that branch
> just because someone rotated the ChangeLog. (But other issues with
> the branch might make it desirable to rebase it anyway, but that's
> beside the point.)

I agree with the decision to not rebase; if we are okay with a merge
commit, then I think the easiest thing would be to place all of the
changelog entries from pr-msvc-support before any of the entries from
master, then manually move any entries dated in 2009 to ChangeLog.2009
in that same order.  But I'd wait to see if anyone else has an opinion.

Another option might be to rewrite the merged ChangeLog, and not touch
ChangeLog.2009, by marking all of the pr-msvc-support entries as merged
entries with an indented date, in this manner:

today's date

        merge pr-msvc-support

        pr-msvc-support date 1

        commit message 1

        pr-msvc-support date 2

        commit message 2

previous master entry date

        master message 1

Again, maybe it's worth teaching 'git-merge-changelog' how to do this
style of indenting dates to represent merges?

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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