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

Previous Next

Full log

Message #101 received at 68929 <at> debbugs.gnu.org (full text, mbox):

From: Jeremy Bryant <jb <at> jeremybryant.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: philipk <at> posteo.net, 68929 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 justin <at> burkett.cc
Subject: Re: bug#68929: [PATCH] Copy which-key from GNU ELPA into core
Date: Sun, 14 Apr 2024 22:52:08 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Jeremy Bryant <jb <at> jeremybryant.net>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  68929 <at> debbugs.gnu.org,
>>   monnier <at> iro.umontreal.ca,  justin <at> burkett.cc
>> Date: Sun, 14 Apr 2024 10:21:24 +0100
>> 
>> > I am currently looking at the merging of history, there appear to be 2
>> > historical commits which exceed the line length in CONTRIBUTE.  
>> > If there is a recommended way to change them please let me know.
>> 
>> I have worked out the change command that work locally to allow these 2 historical
>> commits to be merged.  (with thanks to Stefan)
>> 
>> git merge --no-verify --allow-unrelated-histories --no-edit
>> which-key-integration/which-key-prepare-integration
>> 
>> 
>> FYI the two exceptions were below.  Allowing these would preserve the
>> copyright assignment tracking.
>> $ git log --oneline | awk 'length($0)>78+8'
>> ;; :group 'which-key |ad8eb57 Merge branch 'better-window-sizes' of
>> https://github.com/bmag/emacs-which-key into better-window-sizes
>> ;; :type 'string) |1fd43dc Merge branch 'frame-popup' of
>> https://github.com/bmag/emacs-which-key into pr12
>
> 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?

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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.