From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#68929: [PATCH] Copy which-key from GNU ELPA into core Date: Wed, 01 May 2024 07:31:07 +0000 Message-ID: <87frv256pw.fsf@posteo.net> References: <871q9rvqbi.fsf@jeremybryant.net> <87mssc65y8.fsf@posteo.net> <87y1bwrll4.fsf@jeremybryant.net> <86h6ijxzjk.fsf@gnu.org> <87msrh4kkc.fsf@jeremybryant.net> <87jzml3rlz.fsf@posteo.net> <87wmp2ibjj.fsf@jeremybryant.net> <871q78i9kb.fsf@jeremybryant.net> <86y19gmevj.fsf@gnu.org> <87plurzk6v.fsf@jeremybryant.net> <86ttk2lvz9.fsf@gnu.org> <87edananp4.fsf@jeremybryant.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39139"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 68929@debbugs.gnu.org, monnier@iro.umontreal.ca, justin@burkett.cc To: Jeremy Bryant Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 01 09:31:59 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s24Rb-0009zW-7h for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 01 May 2024 09:31:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s24RL-0006Nw-NL; Wed, 01 May 2024 03:31:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s24RJ-0006NL-3f for bug-gnu-emacs@gnu.org; Wed, 01 May 2024 03:31:41 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s24RI-0001fV-Rd for bug-gnu-emacs@gnu.org; Wed, 01 May 2024 03:31:40 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s24Rd-0002fq-SE for bug-gnu-emacs@gnu.org; Wed, 01 May 2024 03:32:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 May 2024 07:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 68929-submit@debbugs.gnu.org id=B68929.171454869910270 (code B ref 68929); Wed, 01 May 2024 07:32:01 +0000 Original-Received: (at 68929) by debbugs.gnu.org; 1 May 2024 07:31:39 +0000 Original-Received: from localhost ([127.0.0.1]:35908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s24RG-0002fa-H8 for submit@debbugs.gnu.org; Wed, 01 May 2024 03:31:39 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:40899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s24RD-0002fR-JF for 68929@debbugs.gnu.org; Wed, 01 May 2024 03:31:37 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A9F73240101 for <68929@debbugs.gnu.org>; Wed, 1 May 2024 09:31:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1714548668; bh=KefqCxJhuKMIr4dgfVRYvaDliH5/jfnxUX70SXmRAHk=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=CvgXNu5Sv2toNYgPS65HjbKTrb/oij3RTARRH8XYfTaWa+gmgiHOND0ZqjQunk+6Q oJZYg3rTLTNcSL+bG8CN4mVAM+sRhSBNqFrM+4amDROy/YWEATzQ7fyBuDnQbWo2N0 ZR/DJh1WoSz6EoQ5ndE9FmE/qIC9ilpMQGxd9qvTneLJu7pMvnjS/3VFScBJt2TEmN byDfviyL7cyPrfaFkZHLlnxjlJ+Goj4qbpGf3boDjOl4BFtoL1GfC+e2vywKd96i8s DVPD1RR64NoC+QRs1/MxUbfnxccbyI6/Nz3fiw6I9b3wOvgfT6t0QvNSsMwTr6SiO5 5i0CsdiiK9iNg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VTpdl4Nn6z6twp; Wed, 1 May 2024 09:31:07 +0200 (CEST) In-Reply-To: <87edananp4.fsf@jeremybryant.net> (Jeremy Bryant's message of "Mon, 29 Apr 2024 22:00:55 +0100") OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:284240 Archived-At: Jeremy Bryant writes: > Eli Zaretskii writes: > >>> From: Jeremy Bryant >>> 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