[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: Gary V. Vaughan
Subject: Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Date: Tue, 8 Jun 2010 18:19:47 +0700

On 8 Jun 2010, at 15:22, Peter Rosin wrote:
> Hi Gary!

Hey Peter!

> Den 2010-06-08 09:34 skrev Gary V. Vaughan:
>> [[Adding Libtool List]]
>> On 8 Jun 2010, at 08:42, Charles Wilson wrote:
>>> Which is why I don't think even the Peter's long-ready MSVC patches, nor
>>> my pile of pending patches, are candidates for this extremely shortened
>>> release cycle.
>> Regarding these patches, I honestly have paid very little attention to
>> Windows fixes for libtool because I can't test them, and don't use them:
>> So I figured someone else was taking care of it.  Since that obviously
>> isn't the case, and because I'd hate to see them bitrotting indefinitely
>> in the list archives, we can either commit them on the trunk after 2.2.10,
>> or else create a topic branch in git to collect them together for testing
>> and merging back at an appropriate point.
> 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. 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)...

That's my understanding of the "rule" too.

In the (ancient) past with big CVS merges we used to put the merged changelogs
at the top of the current ChangeLog file, with the date lines in the merged
commits indented but otherwise unchanged... but I can't find any evidence
of that in the rotated logs, so maybe we cleaned it up at some point?

> It seems odd both to (a) have entries from 2009 in the (future-to-be) 2010
> ChangeLog and (b) to make changes to the 2009 ChangeLog at this point.
> I see that for the first merge of master into the branch last year I
> updated the dates in the ChangeLog so that they said 2009, but that's
> lying. Sort-of anyway...

I'm not sure what other projects do, and I don't really have a strong
preference either way... but, I suppose, left entirely to my own devices
I would merge the ChangeLogs to retain their date order (including
the rotated out ChangeLog files).  That way, the chronology of what
happened is maintained in order, and git diff still shows what went into
each branch and when the merges happened.

Gary V. Vaughan (address@hidden)

reply via email to

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