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

[Philip Kaludercic]

Jeremy Bryant <jb@jeremybryant.net> writes:

> 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/

Are you proposing that I run this procedure?  I assumed that the authors
issue was still blocking.

-- 
        Philip Kaludercic on peregrine