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

[Peter Rosin]

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:
>
> http://lists.gnu.org/archive/html/bug-gnulib/2010-05/msg00200.html
> http://git.sv.gnu.org/cgit/gnulib.git/tree/lib/git-merge-changelog.c
>
> 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.)

Cheers,
Peter