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

[Patrick Palka <patrick at parcs dot ath dot cx>]

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.