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

Doug Evans
2015-05-16T15:23:30Z

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?