Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Doug Evans <dje at google dot com>]

On Sat, May 16, 2015 at 7:58 AM, Patrick Palka <patrick@parcs.ath.cx> wrote:
> On Fri, May 15, 2015 at 9:00 PM, Doug Evans <dje@google.com> wrote:
>> On Wed, May 13, 2015 at 5:12 PM, Patrick Palka <patrick@parcs.ath.cx> wrote:
>>> This patch syncs our upstream copy of readline to version 6.3
>>> patchlevel 8.
>>>
>>> I basically copied what was done when Jan updated to readline 6.2 in
>>> 2011: http://sourceware.org/ml/gdb-patches/2011-05/msg00003.html
>>>
>>> Specifically, I:
>>>
>>> 1. Extracted the readline 6.3 tarball on top of readline/
>>> 2. Applied patches 1-8 from ftp://ftp.cwru.edu/pub/bash/readline-6.3-patches/
>>> 3. Omitted all the files in doc/ that were intentionally omitted before.
>>> 4. Regenerated readline/configure and readline/examples/rlfe/configure
>>>    using autoconf 2.64.  No other configure files needed regenerating.
>>> 5. Reapplied the only local patch since the update to readline 6.2 that
>>>    has not already been applied to readline 6.3, 05942d8a1 ("Fix
>>>    executable indicator in file name completeion on Windows.").  This
>>>    particular patch has been applied upstream but readline 6.3 does not
>>>    have it.  Whether or not a local patch has already been applied to
>>>    readline 6.3 was determined via manual inspection.  (Wasn't too bad
>>>    really.)
>>>
>>> The new files to make it into the tree are:
>>>
>>>     colors.{c,h}
>>>     configure.ac
>>>     parse-colors.{c,h}
>>>     examples/hist_erasedups.c
>>>     examples/hist_purgecmd.c
>>>
>>> Deleted files:
>>>
>>>     configure.in
>>>
>>> I've been using this patch locally for a few months now and I've
>>> experienced only a single regression which has already been preemptively
>>> fixed by 8900d71e3 ("Explicitly call rl_resize_terminal() in TUI's
>>> SIGWINCH handler").  Other than that, no issues in either the CLI or the
>>> TUI, or changes in the testsuite.  Though I have only been able to test
>>> this patch on Linux.
>>>
>>> Have I missed anything?  What else should be done in order to sync our
>>> copy of readline?  Unlike the last sync from 5.1 to 6.2, this sync to
>>> 6.3 is quite minor and hopefully painless.
>>>
>>> Because the commit is so big and so mechanical I elected to create a
>>> branch users/ppalka/readline-6.3-update where you can view/test the
>>> change.
>>>
>>> readline/ChangeLog.gdb:
>>>
>>>         Import readline 6.3 and upstream patches 1-8.
>>>         * configure: Regenerate.
>>>         * examples/rlfe/configure: Regenerate.
>>>         * complete.c: Reapply previous change.
>>
>> Hi.
>>
>> How does one easily audit whether all local patches are still present?
>> Looking at ChangeLog.gdb I'm left wondering.
>>
>> I'm not saying you've missed anything.
>> Rather, IWBN to have, after all your efforts,
>> a *simple* record of what's still local.
>>
>> One thought was to just nuke all of the old entries
>> in ChangeLog.gdb.  If you say there's only one local change
>> present then it should be a really small file.
>> [IOW, when we import a new readline from upstream,
>> reset ChangeLog.gdb.]
>>
>> Another thought, for those that have an aversion to
>> emptying out ChangeLog.gdb and starting over,
>> is to just add a line that says something like
>> "everything below this line is just
>> for the archive, ignore it otherwise", and copy up entries
>> for local patches that are still local.
>>
>> If the number of local patches is small (as it should be)
>> I like starting over with each new import.
>> But the high order bit for me is to be able to easily
>> audit/track/find local patches.
>
> Another option is that the commit responsible for syncing readline
> should mention which local commits have been reapplied in the commit
> message and also mention it in the ChangeLog.gdb entry.  So the local
> commits at any point in time would be all the commits that occurred
> after the latest readline import plus the earlier commits (if any)
> referenced in that readline import.
>
> I like that idea and the idea of trimming the ChangeLog.gdb file at
> each import too.

Another thought is that IWBN if the reapplication of local patches was
a separate commit.
Even better if each local patch was its own commit, but depending on
the quantity that may be too onerous (I don't think it is, I do this
for every major gdb release in our own tree, but I'm not the one doing
the work here:-)).
I realize this is more work, but IWBN to "see" a local patch with
minimal effort.

Thoughts?