bug#68929: [PATCH] Copy which-key from GNU ELPA into core

[Jeremy Bryant via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jeremy Bryant <jb@jeremybryant.net>
>> Cc: philipk@posteo.net,  68929@debbugs.gnu.org,  monnier@iro.umontreal.ca,
>>   justin@burkett.cc
>> Date: Sun, 14 Apr 2024 22:52:08 +0100
>> 
>> > Is line length the only issue you are looking at?  What about other
>> > requirements of our logs and ChangeLog files, including those imposed
>> > by authors.el?  The most problematic issue is when the file names
>> > and/or its leading directories in the log message don't fit the actual
>> > place and name of the file in the tree.  Did you look at those issues?
>> > They typically come up when preparing a release tarball, and are quite
>> > annoying at that time, especially if there are a lot of them, because
>> > they require manual fixes.
>> 
>> Yes, sorry, I have only looked at the line length because it came up as
>> a blocker.
>> 
>> As far as the file names, this appears stable, but the place in the tree
>> would move as part of this proposed integration, to be in
>> lisp/which-key.el rather than at the root as is the case for the ELPA
>> version.  Is this a problem and how was it resolved with other moves
>> from ELPA to core?
>
> Sorry, I don't remember the details.  I probably fixed some issues by
> hand, and for some others added/modified the relevant data structures
> in admin/authors.el, which see.
>
>> Upon inspection, the earlier historical commits do not generally conform to the
>> Changelog format.
>> How to investigate any issues for authors.el?  Is there a function try
>> and run?
>
> The function is "M-x authors", defined in admin/authors.el.  It first
> updates ChangeLog.4, and then attempts the regenerate AUTHORS; you
> will need to "git reset" to return to the current versions once you
> are finished.  The following extract from admin/make-tarball.txt gives
> some guidance, and more information is available in comments to
> authors.el:
>
>     After "M-x authors" finishes, if there is an "*Authors Errors*"
>     buffer, address the issues.  If there was a ChangeLog typo, fix
>     the relevant entry.  If a file was deleted or renamed, consider
>     adding an appropriate entry to variables authors-ignored-files,
>     authors-valid-file-names, or authors-renamed-files-alist in
>     authors.el.  If some authors are "ignored", consider adding
>     entries to the author-aliases variable.
>
>     If necessary, repeat 'C-u M-x authors' after making those changes.
>
> If you see too many problems than you can handle, feel free to give up
> on them and leave them until the first pretest.

Eli, thanks for the patient explanations however I have not the time to
work on this in detail due to the complexity.


Philip, as you separately proposed to investigate.  Here is a compact
 updated summary of Stefan's prior
 recommendations to merge the history to preserve the contributor
 history/assignments:

"BTW, rather than adding a file, another way to add it to `emacs.git` is
by `git merge --allow-unrelated-histories`.
If you want to do that, you'll want to first create a new commit which
moves the files to their "final" destination, like:

    git rm .gitignore .github Makefile LICENSE.md ...
    git mv which-key.el lisp/which-key.el
    git mv which-key-tests.el test/lisp/which-key-tests.el
    git commit -m 'Move files in preparation for merge into emacs.git'

and then you can `git merge` that new commit into Emacs, preserving
the history.

The commands above should be done in a branch containing the which-key history.
Then you go to a branch of Emacs [add a remote pointing to the which-key
repo modified as above] and do

git merge --no-verify --allow-unrelated-histories --no-edit which-key-integration/which-key-prepare-integration
git push"


Start with the upstream which includes all changes discussed
https://github.com/justbur/emacs-which-key/