branch: elpa/magit
commit 04863968467597cf4e2e9ba6c0cd429fb3e86636
Author: Kyle Meyer <k...@kyleam.com>
Commit: Kyle Meyer <k...@kyleam.com>
magit-rebase--todo: Fix handling of merge actions
Inserting rebase actions into the status buffer when --rebase-merges
is specified triggers two errors with the v4.3.3 release:
1) a type error due to empty lines in the todo list
2) an unbound slot error due to misalignment between the abbrevs list
returned by 'git log --no-walk --format=%h <commit>...' and the
input commits
The first was resolved a few commits back with 621e69eb
(magit-rebase-insert-merge-sequence: Skip over empty lines).
The second error is avoided by 4fc60fdb (magit-rebase--todo: Deal with
duplicated commits). The new logic requests that the git-log call
also output the full hash so that abbrevs can be used as an alist
mapping a long hash to an abbreviated one. But the output lines are
not actually split from the '%H %h' strings into alist entries, so the
magit-rev-abbrev fallback always fires, eliminating the v4.3.3 speedup
that came from the one-shot git-log call.
The known reason for having duplicate commits across rebase todo lines
is that, when constructing commits to pass to git-log, a faulty
always-nil condition prevents the commit from being extracted from the
-C/-c options of merge lines. Once that condition is fixed, I haven't
found a case where two todo lines point to the same commit.
Revert the changes from 4fc60fdb and instead fix the merge condition,
adding an assertion on top so that someone will let us know if they
hit into a case where the resolved number of commits is fewer.
(Also, specify --no-walk=unsorted to ensure commits come back in the
order in which they were passed to git-log.)
Re: #5365
---
CHANGELOG | 7 +++++++
lisp/magit-sequence.el | 15 ++++++---------
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/CHANGELOG b/CHANGELOG
index 52ec379b3b..d79074b1ba 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,4 +1,11 @@
# -*- mode: org -*-
+* v4.3.4 UNRELEASED
+
+Bugfixes:
+
+- Fixed a v4.3.3 regression in inserting rebase actions into the
+ status buffer when ~--rebase-merges~ is specified. #5365
+
* v4.3.3 2025-05-01
- ~magit-section-show-level~ now acts on all selected sections. #5354
diff --git a/lisp/magit-sequence.el b/lisp/magit-sequence.el
index 79560bf59a..57115250ed 100644
--- a/lisp/magit-sequence.el
+++ b/lisp/magit-sequence.el
@@ -1004,21 +1004,18 @@ status buffer (i.e., the reverse of how they will be
applied)."
(forward-line)))
(let ((abbrevs
(magit-git-lines
- "log" "--no-walk" "--format=%H %h"
+ "log" "--no-walk=unsorted" "--format=%h"
(mapcar (lambda (obj)
- (if (eq (oref obj action) 'merge)
+ (if (eq (oref obj action-type) 'merge)
(let ((options (oref obj action-options)))
(and (string-match "-[cC] \\([^ ]+\\)" options)
(match-string 1 options)))
(oref obj target)))
commits))))
- (while-let ((obj (pop commits)))
- (let* ((rev (oref obj target))
- (elt (assoc rev abbrevs)))
- (cond (elt
- (setq abbrevs (delq elt abbrevs))
- (oset obj abbrev (cadr elt)))
- ((oset obj abbrev (magit-rev-abbrev rev)))))))
+ (cl-assert (equal (length commits) (length abbrevs)))
+ (while-let ((obj (pop commits))
+ (val (pop abbrevs)))
+ (oset obj abbrev val)))
actions))
(defun magit-rebase-insert-merge-sequence (onto)
