[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: Peter Rosin
Subject: Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Date: Tue, 08 Jun 2010 12:14:53 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100317 Thunderbird/3.0.4

Den 2010-06-08 11:50 skrev Eric Blake:
On 06/08/2010 02:22 AM, Peter Rosin wrote:
There's already the pr-msvc-support branch, but when I tried to merge
master into it to make it easy to merge back later, the ChangeLog rotation
caused conflicts.

Do you have Bruno Haible's git-merge-changelog program installed on your
machine?  For the longest time, it was just a part of gnulib that you
had to build and install on your own, but it will soon be coming into
its own as a true package:

With that installed, and a couple of lines in your .git/config (or even
globally in ~/.gitconfig), git can do the changelog merging
automatically for you (although it does it in commit order, rather than
date order).

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.

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.
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.)


reply via email to

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