Process magit-todos--scan-with-git-diff failed

[Shinmera]

Hi, I'm getting a very strange error on every magit operation I do, making it quite annoying. *messages* shows the following:

error in process sentinel: magit-todos--async-when-done: Process "magit-todos--scan-with-git-diff" failed with exit code 125. Output:"/usr/bin/nice: a command must be given with an adjustment
Try '/usr/bin/nice --help' for more information.
"

I have no idea what that relates to or where I should look in my environment to figure out what's going on. Any pointers?

[alphapapa]

When did it start happening? What happens if you disable magit-todos-nice?

[Shinmera]

I'm not sure. It can't have been more than some days ago. It doesn't happen on my other machines, but I have very similar setups.

How would I disable that? All I have in my init related to magit-todos is:

(magit-todos-mode)
(setq magit-todos-keywords-list (mapcar #'car hl-todo-keyword-faces))

[alphapapa]

M-x customize-option RET magit-todos-nice RET

Also, why are you setting the keywords that way when magit-todos already does that?

magit-todos/magit-todos.el

Lines 245 to 266 in d85518d

	(defcustom magit-todos-keywords 'hl-todo-keyword-faces
	"To-do keywords to display in Magit status buffer.
	If set to a list variable, may be a plain list or an alist in
	which the keys are the keywords.
	When set, sets `magit-todos-search-regexp' to the appropriate
	regular expression."
	:type '(choice (repeat :tag "Custom list" string)
	(const :tag "Keywords from `hl-todo'"
	:doc "Note that the keywords in `hl-todo-keyword-faces' are treated by it as regexps, while this package treats them as strings. If this doesn't meet your needs, please use another option. See <https://github.com/alphapapa/magit-todos/issues/101>."
	hl-todo-keyword-faces)
	(variable :tag "List variable"))
	:set (lambda (option value)
	(set-default option value)
	(let ((keywords (cl-typecase value
	(null (user-error "Please add some keywords"))
	(symbol (if (and (consp (symbol-value value))
	(consp (car (symbol-value value))))
	(mapcar #'car (symbol-value value))
	(symbol-value value)))
	(list value))))
	(setq magit-todos-keywords-list (seq-difference keywords magit-todos-ignored-keywords)))))

[Shinmera]

Disabling nice seems to remove the errors.

As for why, I'm not sure, might just be leftover config from forever ago. I've had this set up for years and never touched it after the first time.

[alphapapa]

I'm guessing that disabling the use of nice merely obscures the real problem, because you're reporting an error from the branch diff scanner, and nice is still used for the main scanner, which doesn't seem to be signaling an error.

I'm guessing it might have been caused by this commit: 8da7a8e But it probably only happens under certain conditions. So please re-enable the use of nice, then cause the error again, and then check the value of (magit-main-branch) in that repository. As well, please check the messages buffer for any other errors around the same time (if multiple errors happened, you might only have noticed the last one).

[Shinmera]

Okey, here's the log from messages:

You can run the command ‘magit-status’ with C-x g
error in process sentinel: magit-todos--async-when-done: magit-todos--async-when-done: process "magit-todos--scan-with-git-diff" failed with exit code 128.  Output:"fatal: invalid object name 'fatal'.
"
error in process sentinel: magit-todos--async-when-done: process "magit-todos--scan-with-git-diff" failed with exit code 128.  Output:"fatal: invalid object name 'fatal'.
"
"main"

The main there being the result of magit-main-branch.

Also I just noticed that I set hl-todo-keyword-faces earlier in my config, hence the customisation:

(setq hl-todo-keyword-faces '(("KLUDGE" . "#d0bf8f")
                         ("HACK" . "#d0bf8f")
                         ("TODO" . "#D98C32")
                         ("FIXME" . "#EF681F")
                         ("WTF" . "#F8240E")))

[alphapapa]

Ok, please run this command in that repo (ensuring that the same branch is checked out as when the error happened): git merge-base HEAD main

Also I just noticed that I set hl-todo-keyword-faces earlier in my config, hence the customisation:

Ok, FYI, if magit-todos is loaded after you do that, it should include that customization you've made, because the defcustom setter function will read that value. And note as well that setting the value manually precludes the option magit-todos-ignored-keywords from taking effect, because it's accounted for in the same setter.

In other words, this is the classic admonition to not use setq on defcustom options. It will work fine, until it doesn't, and then mysterious behavior will result. In Emacs 29, however, you can use setopt, which runs the setter.

[Shinmera]

git merge-base HEAD main reports: fcff5272894da3427d5f43edb7aee9692ee35f67

FWIW this is the repo: https://github.com/shinmera/multiposter

[alphapapa]

What branch or commit do you have checked out when the error occurs?

[Shinmera]

Current HEAD of main, which is the commit I just posted.

[Shinmera]

I updated all emacs packages on this system and the error seems to have disappeared. I thought I updated the other system I saw the behaviour on already, but I guess I'll try again when I have access to it again later today and will report back.

[alphapapa]

I am unable to reproduce the problem. Using Emacs 29.1:

1. Run mkdir /tmp/test && cd /tmp/test && git clone https://github.com/shinmera/multiposter && cd multiposter.
2. Run with-emacs.sh -e emacs-29.1 -i magit-todos -- -f magit-todos-mode -f magit-status.

The magit-status buffer is shown and there are no errors in the messages buffer. If I add a to-do item to one of the Lisp files and refresh the status buffer, the todo is shown, and still no errors.

[alphapapa]

I updated all emacs packages on this system and the error seems to have disappeared. I thought I updated the other system I saw the behaviour on already, but I guess I'll try again when I have access to it again later today and will report back.

Ok. Make sure to delete old versions of packages, too. And please use this script to try to reproduce the problem in a clean config: https://github.com/alphapapa/with-emacs.sh

[Shinmera]

Okey, the other machine was updated but had autoremovable packages. I guess there must have been interference from a previous version of something or another.

Many apologies for the noise, and thanks a lot for the help debugging this!

[alphapapa]

You're welcome. Thanks.

[alphapapa]

@Shinmera Well, the same error finally happened to me, when I was in an orphan branch in one of my projects' repos. I just pushed a fix for it: a61d6af If you can, please let me know if it fixes the problem for you. Or if you can't reproduce the problem first in order to test it, let me know if anything seems to break, and if not, I'll release it as a bug fix. Thanks.

[accelbread]

Hit this during a rebase. The mentioned fix does not fix it for me.

[alphapapa]

@accelbread I appreciate your report, but I'm afraid I can't do anything without a reproducible test case. There is too much variation between platforms and the various software versions to know what is going on. If you can produce one, e.g. using this comment as an example, maybe it can be solved. As well, the fact that it happened during a rebase could imply a transient problem caused by one scanner or the other seeing worktree files in an inconsistent state, or something like that; if the problem went away, then that may just have to be good enough for now.

[alphapapa]

I found this bug again and am pushing a fix for it in v1.7.1.

@accelbread Maybe the bug you're encountering is a different one or has a different cause. If it happens to you again after upgrading to v1.7.1, please file a new report.